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SYITOPSIS 


The emerging area of Decision Support Systems (DSS) is 
significantly influenced by the ready availability of micro/ 
personal computers and the recent advances in database 
management. The widespread use of spreadsheet analysis has 
involved the managers directly in the decision making process. 
It is expected that the next generation of DSS would make use 
of the sophisticated techniques of Operations Research/ 
Management Science (OR/MS). Such a scenario would integrate 
the user, the display, the interface software, data managemept 
and model management systems. This would facilitate the best 
use of the analytical capabilities of the decision maker and 
the accurate and fast data retrieval capabilities of the 
computer. Ultimately the modelling activity itself need to 
be supported with an integrated system. This dissertation 
is an attempt in this direction, in the area of optimization 
modelling. 

Optimization modelling using mathematical programs has 
been receiving an increasing attention in the recent years. 
This is due to the fact that many real life problems can be 
easily modelled; they also enjoy a good algorithmic support 
and efficient implementations. However, the support from 
the machine to the modeller has been restricted primarily to 
the numerical solution. The other aspects of modelling such 



as, formuilation, data analysis and solution analysis have 
received only a limited attention. Mostly this has been 
in the form of matrix generators and report writers. Many 
of them are implementation specific and lack generality. 

In this thesis we develop an integrated modelling and 
data management system, LAMP, that attempts to provide the 
modeller, support in the entire life cycle of modelling 
process. Our approach has been to conceptualize an archi- 
tecture that encompasses all the activities of the modelling 
phase in situations using mathematical programming. LAMP is 
designed with a general algebraic notation natxrral to mathe- 
matical programs. Features like indexing, symbolic represen- 
tation of entities , (constraints, variables and objective), 
symbolic summation.& special structures have been implemented. 

ThcLAMP has advantages of verifiability, modifiability, docimnent- 
ability and simplicity. The major advantage of such a 
modelling language has been the independence of problem 
structure and problem data, thereby enabling the modeller, 
the meta-level interface with the problem solving software. 

LAMP attempts to integrate the modelling language with 
the other phases of modelling through the concept of relational 
database management. The input data and the results are 
viewed as a set of normalized relations. This approach 
facilitates an elegant structure that can be used as a 
standard data representation. Incidentally this can serve 
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as a naat alternative to the industry standard MPS Format, 

The power of relational database management and standard 
query languages can be exploited to assist the data analysis, 
data validation, solution analysis and report writing phases 
of the modelling with an ease and elegance that far surpass 
the power of matrix generators and report writers. The data 
independence and integrity features permit the structure 
to be implementation independent. Hopefully, such an 
architecture would pave the way for a new generation of 
problem solving systems, in both the area of mathematical 
programming as well as in other areas of management science. 
The ideas are illustrated using an agricultural planning 
model. 

The implementation is based on the problem processing 
software LINDO and UNIFY relational data management software 
using SQL query language. 



CHAPTER I 


INTRODUCTION 

1.1 DECISION SUPPORT SYSTEMS^ 

The application of computers to managerial problem 
solving has witnessed a considerable growth in the last 
three decades, both in quantitative and qualitative terms. 
The quantitative expansion is readily appreciated through 
the massive investments being made by corporations, in 
hardware as well as software, in terms of office automa- 
tion, computerized planning and control systems and communi- 
cation equipment. The qualitative improvement though subtle 
is in fact the more important one. The earlier days were 
marked by the dominance of data processing equipment which 
primarily emphasized mechanization of record keeping and 
accounting functions. The second generation saw a shift 
in emphasis from electronic data processing to management 
information system (MIS), The philosophy of management 
information system laid stress on the use of information 
for decision making. In addition it also saw the emergence 
of models, primarily in the areas of Operations Research/ 
Management Science (OR/MS) to help the managerial decision 
making activity. Optimization techniques with emphasis on 



efficiency were increasingly applied leading to optimal 
decision rules. The early success of this approach did 
contribute substantially to the emergence and growth of 
management science. 

Despite the tremendous growth in computer^relatad 
activities, the field of Management Information System, 
had little significant impact on the style_ and/or process 
of managerial decision making. This can be traced in 
large part to the lack of proper perspective on .the problems 
involved in augmenting the decision making ability of 
management [llS]. The philosophy of decision support 
is primarily intended to overcome this limitation. 

This new approach, generally known as Decision 
Support System (DSS) philosophy, shifts the emphasis from 
the efficiency/, of. decision making to the effe ctivene ss of 
decision making [ 5 ] . To quote Peter Drucker, efficiency 
emphasizes dqing_ things r ig ht, while effectiveness 
emphasizes doing, right thi ngs . The decision support 
approach recognizes the followings 

(a) difficulty of communicating the utility of sophisti- 
cated Management Science/Operations Research technique 
to practising managers.. 

(b) lack of appreciation of the complexities of real 
world by the Management Scientists/Operations 
Researchers. 



(c) apprehension that, an imposed optimal solution may put 

into question, the value of experience, maturity, 

judgement and wisdom gained by real world practice. 

Recognizing these realities the DSS philosophy tries 
to support decision making rather than substitute decision 
makers through the use of models. It also lays considerable 
stress on the involvement of the decision maker directly in 
the decision making process, rather than his indirect involve- 
ment through the management scientists, which often is 
considered to be the essence of MIS approach. 

Developments in two distinct areas within the last few 
years have made the D,SS approach particularly appropriate [ll8] 
First, there has been considerable technological progress - 
the evolution of computer equipment with substantial power at 
affordable costs, the technology of database, the personal 
computer revolution making computing power available at desktop 
the communication revolution enabling remote access to data 
and resources, the emergence of interactive computing and the 
low cost availability of usen-friendly software [lis] . The 
second development in the last few years has been a conceptual 
one. An understanding of the inherent structure of informa- 
tion systems within organizations is emerging. Also, we are 
adding to our knowledge, the ways in which human beings solve 
problems and the ways in which we can build models that 
capture aspects of their decision making processes. These 
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insights provide us with some important concepts for system 
design [l5l]. 

The progress in these areas have been dramatic, and 
our planning and control systems should reflect the new 
capabilities. We now can build entirely new kinds of systems 
that dynamically involve the manager’s judgement and support 
him with flexible access to data and models. These systems 
are known as Decision Support Systems. 

1.2 OPTIMIZA.TION MODELLING J 

Most people think of a model as being a small-scale 
version of a large object - a model' ship or a model plane. 

The sense in which models are used in Management Science is 
analog ouSf hut not quite the same. Ships can be scaled down 
with no material loss of realism in certain important charac- 
teristics. But business systems cannot be scaled down easily. 
We need a representation, which will behave similarly. A 
business contains legal, psychological, sociological, engineer- 
ing and other factors and is a very complex affair. It cannot 
be represented in a scaled down form without serious over- 
simplifications. After prolonged experimentation with various 
sorts of representations, it has been found that a mathematical 
model is a useful kind of model of a business enterprise. The 
set of mathematical equations does not bear any physical 
resemblance to the business enterprise, of course, but the 



equations can be chosen so that the values of variables 
relate to one another in a manner comparable to' the relation- 
ships between variables in the organization. If the variables 
in the model have real counterparts, and if the relationships 
between the variables in the model correspond closely to the 
relationships in the real business system, we should be able 
to test the probable effect of charges in the real system 
by making equivalent changes in the model. Evidently, there 
is a great need for care in devising the system of equations 
so that the predicted outcomes are realistic. 

The great advantage of Decision Support Systems is that 
the equations do not need to deal with all the factors at the 
same time and one can even omit some of them. The manager 
can supply his own estimate' for some of the parameters based 
on his experience.. Conversely, the manager can safely rely 
on his model to carry out the num.orical and analytical parts 
of the process. The interaction of tho manager v/ith the 
model permits the strengths, of the computer and the strengths 
of the manager to be brought to bear on the same problem at 
the same time. The intuitive judgement of the manager, with 
his years of experience of the business system cannot be 
computerized. Similarly, the data storage and retrieval 
capacity of the machine and tho calculating power of the 
model using the machine are far beyond the capabilities of 
a manager. Each can contribute to the decision through a 
decision support system [lis]. 
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The use of models in management science is definitely 
not new. However, their application using the decision 
s'upport approach is relatively new. In fact, this has led 
to a situation, where the discipline of modelling has advanced 
rather slowly while the disciplines concerning the analysis 
and development of techniques to solve such problems have 
grown much faster. It is imperative at this stage to redress 
this imbalance, as has been pointed out by Geoffrion [76] 
recently. 

The first attempt at modelling in a supportive environ- 
ment, came rather interestingly through the simple spreadsheet 
modelling [23,75,76]. This gave the practising manager, an 
opportunity to get involved in the modelling process directly, 
While the power of spreadsheets is definitely limited, the 
richness of its applications in real life has almost created 
a revolution [49]., In a parallel vein, modelling languages 
like IFPS [80,134] had been steadily in use in restricted 
areas of management like Financial Planning. What is needed 
now is to extend the scope of modelling systems that are 
directly used by managers, to include the capabilities of 
the sophisticated techniques of Operations Research/Management 
Science. 

Among the several techniques of Operations Research/ 
Management Science, optimization models using mathematical 
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programming have been the most extensively used toolS. 
Mathematical programming in general and linear programming 
in particular have the following significant advantages® 

(a) ability to model a wide variety of applications 

(b) availability of tools/techniques to solve reason- 
ably large problems that occur in real life 
situations. 

The early applications of linear programming did evolve 
from simple numerical analysis software into sophisticated 
matrix generators. However, to embed optimization techniques 
within a decision support environment one needs to enlarge the 
scope of such software to the entire life cycle of modelling. 
This alone will allow a true interactive modelling capability 
rather than a mere solution capability. Such an approach will 
create a re-emergence of mathematical programming applications, 
improve modeller productivity, enhance the modeller-manager 
communication and ultimately to a better acceptance of the 
models [ 76 . 1 , The research reported in this thesis is primarily 
to design a support system for such a situation. Such an 
exercise, it is hoped, will lead to a new generation of 
decision support systems. Moreover the ideas developed would 
be useful for generating far more general decision support 
systems that may involve many of the techniques of Operations 
Research in an integrated manner. Geoffrion' [76] has recently 
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pointed out the benefits of such a philosophy, which, he 
terms a general modelling framework. 

1.3 OUTLINE OF THE THESIS”. 

Chapter II contains the literature review. First the 
developments in the area of decision support are reviewed. 

This is followed by a review of the literature pertaining to 
problem processors, matrix generators and modelling languages 
for mathematical programming. The capabilities of a number 
of iiSE existing matrix generators is contrasted with the 
capabilities of a number of emerging modelling languages. 

The need for a model management system with enhanced capabi- 
lities of data management is established. 

Chapter III outlines the research goals of our modelling 
system LAMP alongv/ith the possible benefits arising out of 
research efforts in this direction. 

Chapter IV covers the various features of the modelling 
language proposed in this thesis. The syntax of the language 
is specified in the form of an EBNF Grammar [9S], Next 
follows, the features of the language, its capabilities and 
the implementation details. A sample problem illustrating 
the details is also provided. 

In Chapter V the need for an interface between the 
modelling language (s) and problem processor (s) is established. 



A standard in the form of a set of relations to represent the 
data associated with arbitrary linear programs is proposed. 

Chapter VI demonstrates the use of a standard rela- 
tional database management and a query language to accomplish 
the model maniptfLation functions. A wide variety of analysis 
and report writing capabilities that is typically needed in 
most modelling situations is accomplished using the query 
language. 

Chapter VII summarizes the conclusions and lists the 
recommendations for further research work in this area. 



CHAPTER II 


LITERATURE SURVEY 

2.1 INTRODUCTIONS 

Decision Support Systems (DSS) represent a broad based 
specti*um of ideas that support the executive decision processes 
with flexible access to data and models [ 118 ], The DSS approach 
emphasizes the fact that management involves primarily decision 
making and managers need a direct support, through tools and 
techniques in the decision making activity. The revolution 
in computing power in general and micro-- computing in particular 
has helped in translating this support philosophy into real 
life applications by involvement of the decision maker in the 
modelling processes [22]. In fact decision support systems 
and associated modelling represent a renewed interest in 
Operations Research/Management Science (OR/MS) techniques [32]. 

It is generally observed that optimization represents a 
major application technique in the entire gamut of OR/MS 
techniques. Several studies have established this observation 
[121]. Linear Programming (LP) has enjoyed a widespread 
acceptance, due to ease of use, that is characteristic of 
linearity of constraints and objective function. Consequently, 
linear programs involving several thousand of variables and 
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several hundred o.f constraints have been traditionally solved 
in such diverse industries like Petroleum, Food, Transportation, 
Energy and Service Sector [.176]. Almost all application oi 
LP made e^ctensive use of computational facilities leading to 
several software products called LP Packages. Applica.tions of 
Nonlinear Programming (NLP) to real world problems are emerging 
only recently. Such systems that lend computational support to 
the solution of mathematical programming problems are usually 
referred to as Pro_M.em_ Processors. They have evolved conside- 
rably in terms of power and cpmplexity in the last four decades. 
The early LP Packages primarily ej<ploited the numerical problem 
solving capability of the digital computer [ 75] . Undoubtedly, 
but for the availability of a digital computer there was no 
possibility of solution. Yet, the numerical analysis is only 
a small part of the overall solution process. Modellers soon 
started looking for support in non-numeric computation as well, 
leading to the early matrix generators. 


Linear programs are expressed in one kind of form for 

human designers or modellers, but in a quite different form for 

computer algorithms. Thus the translation from modeller's form 

to the algorithmic form is an essential task. Traditionally, 

this task of translation has been divided between human and 

computer through the writing of computer programs known as 

& 8 ] 1 * 

matrix generators (MG)^ A matrix generator is a computer 
program that writes out the algorithmic form i.e,, the 
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coefficient matrix of a linear program. Firsts a person reads 
the modeller’s form and writes a matrix generator program for 
it. Then the matrix generator program is executed to produce 
an algorithmic form. Very soon they were found to he inadequate 
and often artificial [68]. As a natural consequence this led 
to the growth of modelling language systems as an alternative 
approach. 

A modelling language system leaves almost all the work 
of translation to the computer. The key concept to such an 
approach is a computer readable modelling language that expresses 
a linear program in the same manner that a modeller does. Further, 
it is observed that modelling languages lead to a more reliable 
application of linear programming at a lower overall cost with 
reference to verification, modification, documentation, indepen- 
dence and simplicity aspects [68]. Modelling languages also 
provide a flexible access to modelling by providing support in 
all four stages of modelling viz. formulation, data analysis, 
numerical solution and analysis of results. 

Many of the real life models using linear programming 
need large volumes of data to be processed as part of the solu- 
tion process. The iob of managing this large volume data is 
by no means a trivial job. Efforts to integrate data manage- 
ment fmctions have been attempted elsewhere in an independent 
manner. With the tremendous growth in database technology in 
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the recent years we feel that the integration of database 
techniques will go a long way in building powerful model 
management systems. This will be reflected in the philosophy 
of our approach outlined later. . 

The evolution through the matrix generators, model 
management tools and the recent intelligent systems for 
mathematical programming [83] is indeed impressive. ¥e take 
stock of these developments in the subsequent sections, which 
provide the background for our work. Our work proposes an 
architecture for the next generation of problem processors, 
that build on the strength of the current problem processors. 

A representative system incorporating this architecture is also 
built,' to demonstrate the power of the designs using this 
architecture, which is the major thrust of this thesis. 

2 . 2 PROBLEM PROCESSORS 

Solving even small mathematical programming problems 
demands a prohibitive amount of computational effort, if under- 
taken manually. Thus all practical applications of maxthematical 
programming require the use of computers. In this section we 
examine the role of the digital computers in this task. The 
task of solving linear programs is greatly facilitated by the 
very efficient linear programming codes that computer manufac- 
turers provide for their computer models. The representative 
ones being IBM’s MPSX [92], CDC’S APEX [47], Burrx)Ugh»s 
MODELER [33], Honeywell’s MPS [89] etc. Recently independent 
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softwares like LINDO [145], GINO [114], GRG [HI], MINOS [128] 
have come into being. In a matter of one or two days, a 
potential user can become familiar with the program instruc- 
tions thfit have to be followed, in order to solve a given prob- 
lem using a specific commerpial code. The ample e.vailability 
of computer codes of good quality is one of the basic reasons 
for the increasing impact of mathematical programming on manage- 
ment decision making. Many of the codes have an extended 
capability to solve integer and limited nonlinear programming 
problems (separable problem*s, linearly constrained nonlinear 
optimization problems, etc. ) as well. From simple, rigid 
computer programs of the yester-years, the modern linear pro- 
gramming codes have evolved into sophisticated systems with 
modules that handle input information, provide powerful compu- 
tational algorithms and report the model results. Most of these 
advances have been made possible by developments in software 
and hardware technology as well as break- throe^hs in mathema- 
tical programming theory. The continual improvement in compu- 
tational capabilities of mathematical programming codes is in 
reducing running times and computational costs, to facilitate 
solutions of larger prpblems "md to extend the capabilities to 
more general non linear, discrete optimization. In the next 
sub-section we will take stock of the basic features common to 
all good current-day systems emphasizing the important concepts. 
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2.2.1 Basic_Feature_s 

The basic features can be broadly classified intoS 

a) Input Specifications 

b) Solution Techniques 

c) Output Specifications 

a) Input^^Spej;J.ficat^^ 

The first task when solving a linear programming model 
using a computer code is the specification of model structure 
and the input of the corresponding values of the parameters. 
The important elements, the user has to specify are* 

. Number of the decision variables, constraint (s) , 
objective function(s), right hand side(s) 

. Numerical values of the cost coefficients, matrix 
coefficients and right hand sides 

, Nature of the constraint relationship 

. Free and bounded variables 

. Nature of the optimization 

. Title of the problem. 

To facilitate easy and meaningful analysis/retrieval,^ 
symbolic identification of variables and constraints through 
names (typically of eight characters length) are provided. 
Typically only non-zero ■ coefficients need to be input. Several 
small systems allow free-form input e.g., MPOS [46], Many of 
the codes have evolved over the years, a standard called MPS 
format, originally used by IBM»s MPSX [92], This standard 



has become archaic and we will propose an alternate elegant 
relational format, later in this thesis. 

Input specifications also include several summary 
results of the data to help the user, undertake checks for 
consistency; typical exam.ples beings 

Row, column count 

, Matrix density (percentage of nonzero coefficients) 

. No, of nonzero elements in each row and each column 

. Values of the smallest and largest element in the 
coefficient matrix, right hand side (s), objective 
function (s) 

. Print-out of equations in expanded form 

, Picture of the full coefficient matrix or a condensed 
form of the coefficient matrix. 

Sometimes, input data need to be scaled. The simultane- 
ous presence of both large and small numbers in the matrix of 
coefficients should be avoided whenever possible because it 
tends to create problems of numerical instability. This typi- 
cally can be avoided by changing the unit of measure of a given 
variable, say from kg to 1000* s of kg. 

Later in this chapter we will see further evolution of 
input specifications into full fledged softv/are systems known 
as matrix generators. 
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b) Solution lec^iques* 

There has been considerable concern in the development 
of problem processors to reduce the computational time required 
to solve programming problems, by improving the techniques used 
in the optimization stage of the problem. This has been accom- 
plished primarily by refinements in the matrix- inversion pro- 
cedures using triangularization; representation using sparse 
matrix technology} path selection criterion by allowing multi- 
ple pricing of several columns to be considered as possible 
incoming variables; use of more efficient pre- solution techni- 
ques by providing crashing options to be used in order to obtain 
an initial feasible solution or by permitting the user to specify 
initial basis. To avoid the presence and/or growth of numerical 
errors, most codes use original values of the coefficient matrix 
to reinvert the basis periodically, ' This process maintains 
accuracy. The frequency of reinversion can be user specified. 

Also the user is allowed to specify feasibility toleran ces that 
are designed to check whether or not the values of non-basic 
variables and the reduced cost of the basic variables are zero. 
There are also pj-vot 'tolera^^^^ that prevent coefficients 

very close to zero from becoming a pivot element in a simplex 
iteration. If necessary the systems allow high pj-ecisipn^apith- 
metiq (generally double precision) to be specified by the user 
to decrease the computational errors. In essence, the systems 
allow control of the .solution process by the user in a detailed 


way. 
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c) Outpirt_Specifica_tj^nsS 

Typical output information provided by standard commercial 
codes includes^ 

. Optimum value of the objective function and optimal 
values of the decision variables 

. Slacks/ Surpluses in the constraints 

. Shadow prices for the constraints 

Reduced costs for the decision variables 

. Ranges on the coefficients of the right hand side 

. Ranges on the cost coefficients 

. Value transitions resulting from changes in right 
hand side/cost coefficients 

. Sensitivity and Parametric Analysis. 

Occasionally some of the codes provide summary results 
for reporting to management directly. Others provide a report ■ 
writer program that can be user written and appended to the 
system for report generation. V/e will review some of the 
capabilities in our discussion of matrix generators in the 
next section. 

2.2,2 Current Trends s 

The current trends in the evolution of problem processor 
include development of model management system (discussed later 
in Section 2.4); improved sophistication in their ability 
to solve nonlinear and integer programming problem, reviewed 
in [175]; porting the software to micro computers resulting 
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in a rich collection of micro based software for mathematical 
program, reviewed in il48, 149]., adding gr^hic support, 
reviewed in [l75] , adding explanation capability to linear 
programming packages [ S3] . Spurred by the spread-sheet 
revolution [23], planning languages are being increasingly 
used by modellers. Extending optimization capabilities to 
planning languages is being explored rather recently. IFPS/ 
Optimum ["80 ], VINO [49] represent two philosophies, in this 
direction. 

2.3 MATRIX GENERA.TORS : 

As mentioned previously, a matrix generator is a computer 
program that writes out the algorithmic form i.e., the coeffi- 
cient matrix of a linear program, A number of matrix generator 
and report writer systems which we term as matrix generators 
essentially use a standard mathematical programming processor. 
These systems are quite significant for any organization that 
uses mathematical programming (MP) as a serious modelling tool. 
These systems include matrix-generator (MG) programs and 
report-writer (RW) programs which may be written in high-level 
computer programming languages viz. FORTRAN^ ALG-OL, PL/l or in 
a special-purpose matrix generation and report vn'iting la.nguage 
In such a system, first the matrix-generator program reads and 
processes the "PROELEM DATA " presented in the form of sets of 
tabulated data to produce a card image of INPUT FILE ; then 
the solver or optimizer generates solution values| finally the 
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report-writer program extracts relevant information and 
presents in a desired format. The card image "liNIPUT FILE" 
contains row names that are coded by suitable text expressions f 
column names that are also coded by appropriate text expres- 
sions; the coefficients of the problem matrix; the RHS (right 
hand side), BOUNDS and RANGES information; some information 
concerning starting basis. The report- writer program generates 
the specific information from the solution values obtained by 
the optimizer and presents the same information in a suitably 
tabulated format. The report-writer program usually refers 
the "PROBLEM DATA" from the 'INPUT FILE" and may also carry 
out some arithmetic operations on the solution values to generate 
desired information. 

The most prominent among a number of matrix generator 
and report writer systems are% 

MODELER (Model Development Language and Report Writer) 

. developed in 1980 by Burroughs Corporation [33]. 

MaGen (Matrix Generator) 

. developed in 1977 by Haverly systems Inc. [86]. 

MGRW (Matrix Generator and Report V/riter) 

. developed in 1972 by IBM World Trade Corporation [91], 
GAI#IA (Version 3.4) 

. developed in 1977 by Sperry Uni vac Computer System [154], 
DATAFORM (MPS-III Version) 

developed in 1975 by Ketron Inc. (I08] . 
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APEX (Version - III) 

. developed in 1979 by Control Data Corporation [ 47 ] . 

These systems commonly incorporate at least the follow- 
ing features; 

input of problem data in a tabular form 

. construction of row and column names by name 
expression 

. use of constants or arithmetic expressions to 

specify the matrix, RHS, BOUND, etc., coefficient's 
by suitable row or column generator clause (procedure) 

. access to the solution file to obtain solution 
values, reduced costs., ranges, etc. 

. formatted and printed tabular information. 

Current matrix generators incorporate their own MG 
languages in which the programs are written. They commonly 
presume a sequence of four forms; modeller’s formj MG form. 
Standard (MPS) algorithmic form, and specialized algorithmic 
form. These languages incorporate loops, assignments, trans- 
fer of control or other executable statements in describing 
the computer program. 

Matrix generation is certainly a great advance over 
translation by human labour alone, particularly for very- 
large linear programs. However, they suffer from potential 
difficulties viz. verifiability, modifiability and documenta- 
bility which are aggravated by introduction of matrix- gene rat or 
form,^ The associated drawbacks of matrix generators areS 
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yerifiajDility;l This being the ma'jor consideration in a 
linear program, refers to dete’rmining whether modeller’ s 
form correctly represents the reality and also determining 
whether the algorithmic form is a correct translation of the 
modeller’s form. The verification of matrix-generator program 
necessitates program debugging at the cost of human time and 
computer time, ■ ■ ' ■ _ 

Mpjiifiaby.i^ This relates to determination of new m.odeller’ s 
form corresponding to any change in real life problem situation 
and translating the new modeller’s form to a new algorithmic 
form. Thus in the case of matrix generators, any modification 
essentially aroodnts. to revising matrix-generator computer 
program which again aggravates the task of program debugging. 

Documentabii ity £ This relates to maintaining of all relevant 
information pertaining, to different, foms and their relation- 
ship., The matrix generator requires additionally, documenta- 
tion of matrix-generator program, which is fairly lengthy,, 
time consuming and unpopular with programmers; yat inadequate 
documentation can eventually make it difficiilt to use or 
change a program. 

The matrix generators also have drawbacks related to 


the following areas 
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Indeperuiencei The weakness of matrix generators lies in their 
involvement with the algorithmic form. The conceptual binding 
with particular algorithmic form imposes restrictions with 
regard to features viz. naming of LP components, ordering of 
coefficients and representation of special constraints. This 
in turn necessitates modeller's familiarity with particular 
algorithmic form which could be avoided only at some additional 
cost. 

Simplicity s The final drawback of matrix generation stems 
from the basic approach of translation task i.e., introduction 
of intermediate MG form. This additional form increases the 
modeller’s burden and complicates the conceptually simple job 
of translation of modeller’s form to algorithmic form. 

Further, the majority of matrix generators are more 
influenced by the algorithmic form i.e., ffPS form. Therefore, 
■the modellers using these matrix generators have to follow 
various conventions and restrictions of matrix-generator 
data format and of MPS form at the cost of extra vTork and 
complication. These above mentioned difficulties lead to 
the development of modelling languages described in next 
section£6^. 
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2.4 MODELLING LMGUAGES ? 

Modelling Languages (ML) as mentioned earlier are 
natural evolution from the matrix generators. They are 
designed to provide a superior support in all the phases 
of modelling. In this system, the modeller first creates a 
symbolic modelling language description of the mathematical 
program of interest and then a computer system reads the 
above symbolic description along with the corresponding 
explicit set and parameter data to translate it to the desir- 
ed algorithmic form. Thus a modelling language system serves 
to divide the work of translation between a person and com- 
puter with greater portion of work shared by computer as 
compared to matrix generators. MLr-like systems for linear 
programming have mostly been developed since late seventies. 

The more sophisticated of these languages incorporate some 
kind of symbolic indexing, in order to conveniently represent 
fairly large models. The major systems employing modelling 
languages’ features are ALPS [170], GAI'IS i.lQ5] , MO [L24 ] , . 

LP MODEL [103], MAGIC [52], MGG [l47], UIMP [167], 7ML [68], 

SM [75 ] . They are further outlined below. 

ALPS (Adv^ced_ Linear Programing System) s 

ALPS is an easy to use mathematical programming package 
developed in 1977 by United Computing Systems, Inc., Washington, 
USA. The modelling language uses ’’FOR’’' loop statements to 
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define constraints. The language notation is fully algebraic 
and it incorporates general linear expressions v;ith limited 
variety of indexed sums. The data description is based on 
symbolic parameters only and subscripted identifiers are 
used for model -component names. It allows for coefficients 
to be given in a row-wise organization. Special constraints 
such as simple bounds can be described like other constraints. 
The model description is independent of explicit data. Further 
details regarding major features are available in [158] . 

GA MS ( General Algebraic M odelling Systemjs 

A general algebraic modelling language package was 
developed at the World Bank Development Research Centers 
Washington, USA. It has been in extensive use since 1979. 

The modelling language uses assignment statements. The lan- 
guage notation is algebraic with some exceptions and it 
incorporates general linear expressions and indexed sums. 

The data description is based on symbolic sets and parameters 
and subscripted identifiers are used for model component 
names. It allows for coefficients to be given in a row-wise 
organization. Special constraints such as simple bounds can 
be described in a special manner. The model description is 
not independent of explicit data. Further details regarding 
major features are available in [l2l] . 
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LMC (Linear Modelling Cap^ility2} 

A subsystem of Conversational Modelling Language (CML) 
was developed at Yale University Institute for Social and 
Policy Studies Center, Connecticut, USA. It has been in use 
since 1977« The modelling language uses assignment statements. 
The language notations are English like rather than algebraic 
and it incorporates general linear expressions and indexed 
sums. The data description is based on symbolic sets and 
parameters and subscripted identifiers are used for model 
component names. It allows for coefficients to be given in 
a row-wise organization. Special constraints such as simple 
bounds can be described like other constraints. The model 
description is independent of explicit data. Further details 
regarding major features can be found in [124] . 

LPMODEL (Linear Pr ogra mming .Modelling^ L^guage) J 

A modelling language system for linear programs was 
developed at IBM Israel Scientific Center, Haifa, Israel. It 
has been in use since 1980. The language notation is alge- 
braic with moderate alteration (e.g. , "SIM" for summation 
notation) and it incorporates general linear expressions and 
limited indexed sums. The data description is based on 
symbolic sets and parameters implicitly defined and concate- 
nated identifiers are used for model component names. It 
allows for coefficients to be given in a row-wise organization. 
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The model description is independent of explicit data. Further 
details regarding major features are available in Ll03] . 

I^GIC_ ( Mat r ix G en er at o r_In struction Con verto r )_s 

A modelling language package was developed at University 
of Edinburg, Scotland. It has been in use since 1982. The 
modelling language uses "FOR" loop statements to define 
constraints. The language notation is fully algebraic and 
it incorporates limited linear expressions and general 
indexed sums. The data description is based on s 3 raibolic 
parameters only and subscripted identifiers are used for 
model component names. It allows for coefficients to be 
given in a row-wise organization. Special constraints such 
as simple bounds can be described like other constraints and 
ranges can be described in a special manner. The model des- 
cription is not independent of explicit data. Further details 
regarding major features of this system are available in [52], 

MGG Genexatjjr ,G_enerai^ 

A modelling language package was developed by Scicon 
Computer Services Ltd. , England. It has been in use since 
1975. The language notation is fully algebraic and it incor- 
porates very limited linear expressions and indexed sums. 

The data description is based on symbolic sets and parameters 
and subscripted identifiers are used for model component names. 
It allows for coefficients to be given in a row-wise organiza- 
tion. Special constraints such as simple bounds and 
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generalized upper boimds along with ranges can he described 
in a special manner, '^he model description is independent 
of explicit data. Further details regarding major features 
can be found in [l46 ] . 

e f or Mat hematical Programs )j 

A mathematical programming package was developed by 
UNICOM Consultants Ltd. j Surrey, England. It has been in use 
since 1976. The modelling language uses loop, assignment 
statements and transfer of control to define constraints. 

The language notation is fully algebraic and it incorporates 
very limited linear expressions and general indexed sums. 

The data description is based on symbolic sets and parameters 
and subscripted identifiers are used for model component 
names. It allows for coefficients to be given in a row- wise 
or column wise organization. Special constraints such as 
simple bounds and ranges can be described in a special manner. 

The model parameters may be independent of explicit data. 

Further details regarding major features are available in [6l]^(6^ 

.Prototype ,MpdellJ.ng I^anguag_e )i 

XML is a hypothetical modelling language based on the 
sort of modeller’s form. It has been developed by Fourer at 
MIT, Cambridge, USA. The modelling language system has five 
major sections^ sets, parameters, variables, objective and 
constraints. The language notation is algebraic with moderate 
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alteration and it incorporates both indexing and arithmetic 
expression. The data description is based on sjTiibolic sets 
and parameters and subscripted identifiers are used for model 
component names. It allows for coefficients to be given in 
a row-wise organization. It is syntactically and semantically 
simpler, A detailed specification of the modelling language 
system is available as technical report by Fourer [ 6?] ^ [fisj. 

SM (st ructure d _ Mq del ^ 

SM is being developed at Western Management Science 
Institute, University of California, Los Angeles, USA. It 
endeavours to provide a formal mathematical frame work, 
language and computer based environment for conceiving, 
representing and manipulating a wide variety of models. The 
frame work uses attributed acyclic graphs, set partitions 
and hierarchies to represent the semantic as wall as mathe- 
matical structure of a model. The language is computer 
executable and yet natural for novice users. The computer 
based environment is evolving. Further details regarding 
salient features can be found in [76], 

Other systems like LINDO [1^5], MPOS [46] do have 
the flavour of modelling language even though they are pri- 
marily problem processing systems. 

Critical examination of the modelling systems reveals 
the following?; all of them use modelling languages that 
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resemble modeller’s form to some degree and do not involve 
programming, though traces of programming languages forms 
can be found especially in ALPS and UllfP. UIMP and MGG use 
I^S naming schemes i.e., eight characters-long names for 
their entities v^hereas other systems do not have such 
restrictions. All of them permit a constraint-wise (roW“wise) 
organization, except UIMP, which allows column-wise organize- 
tion also. All except LPMODEL use subscripted identifiers 
for naming model components; LPMODEL use (Concatenated identi- 
fiers of unrestricted length for the similar purpose. ALPS 
permits _c[uadratin objective. MAGIC, MOG, UIMP and ALPS 
support discrete (integer) optimization model as well. ALPS, 
MGG and UIMP are available as ' commercial product s[6aj. 

As a group, the greatest strength of these systems is 
their ability to raise the productivity of optimization 
applications. The serious vreakness of most of these systems 
is that they are wedded to one particular modelling paradigm 
and lack generality to encompass most of the other modelling 
paradigms developed in OR/MS. They also lack integrated 
facilities for query and immediate expression evaluation. 

The above observations match with the aims of structured 
modelling (SM) and suggest for the need of an appropriate- 
system providing s 3 nithesis of model management, data manage- 
ment and associated interface^ which is the focus of this 


thesis. 
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2.5 data managements 

2.5.1 I nt r o duct i on » 

Integrating several sets of data needed by several 
applications and sharing the data resource for simultaneous 
access by several authorized users has been the dream of 
information scientists. This has been made possible with 
the technological growth of computer storage devices capable 
of storing large volumes of data at a lesser cost, in the 
recent years. This is generally termed the technology of 
database. A modem definition of datahase is a set of 
structured data stored on the computer accessible media that 
satisfies the needs of several users simultaneously, in a 
selective manner yet in a reasonable time frame. In order to 
effectively manage such a database, a sophisticated software 
is generally needed. Such a software is generally termed a 

system (DBMS) . Basically a DBMS provides 
the means of organizing data on peripheral storage devices 
and retrieval procedures necessary for internal processing 
of the stored data. The user first describes the structure 
of the data and the tasks in abstract terms and leaves the 
job of determining the best operating mode to tho database 
management system. The database structure is described at 
the conceptual level by a logical schema which provides a 
yiev^ of tho data to the user. At the internal level the 
structure is specified by a physical s che ma . Usually the 
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structure is specified to the DBMS using a dat a de finition 
language (DDL); the manipulation of the data stored in the 
database is specified throiagh a da_ta_manip_iiation_la^ 

(DML) . The foundation for the structure, however, is the 
notion of a data^ model described in the next section* 

2.5.2 Data Mo del I 

The data model is a structured tool used to understand 
and interpret the real world. In order to facilitate communi- 
cation, it is useful to regroup the real world objects with 
v/hich we are interested, into homogeneous classes. A data 
model allows one to define relationships which may exist ■ ■■ 
between different classes of objects. Reflecting different 
views of 'the relationships amongst the classes of objects 
several data models have been proposed in literature. Of 
these, there are three prominent data models' viz. the hierar- 
chical model, the network model and the relational model 
which evolved over the last decade. Using hierarchical 
approach, conceptual model is viewed as a tree graph where 
nodes represent classes of objects and branches represent 
association between two classes. Hierarchical graphs have 
a root and the nodes emanating from root are labelled as 
sons, grandsons jetc, of the root. Using the network approach, 
the conceptual model is viewed as rm ordinary graph where 
nodes represent classes of objects and arcs represent associa- 
tion between two classes. The network model differs from 



hierarchical model in that there is no hierarchical limita- 
tions on association. An introductory description of major 
data models is available in DBMS texts [50,16'^ > 166]* The 
widely used hierarchical model based system has been the 
IBM’s IMS (Information Management Systems). The CODASYL 
(Conference on Data Systems Languages) Committee’s recommen- 
dations were based on a Network Model, Consequently a ^ 

number of implementations based on network approach were 
made available in the last decade by several main frame/mini- 
computer manufacturers including IDS [ 40 ] from General 
Electric, DBMS~10 [57] from Digital Equipment Corporation. 

The growing importance of the relational model in the recent 
past suggests that it is likely that the models in the future 
will be predominantly relational (due to reasons elaborated 
in the next section). 

2*5.3 R elat ional pata_ Models 

The relational data model views the logical schema as 
tables having rows and columns, where each row represents a 
record and columns represent various attributes (fields) 
related with the object. The tabular arrangement of data is 
an elegant representation. This model is based on the 
feature of a mathematical relation which is a set of tuples 
having tuple elements as attributes of the object. The 
mathematical foundation of relational data models permits 
elegant and concise definition and deduction of their 



properties [38]. The relational concept was first applied 
through AOV (attribute, object, value) theory along with an^ 
algebraic theory of data proposed by Childs [39], about 1968. 
Later around 1970 Codd [^3] proposed the relational data 
model concept based on^notion of relation. Being conceptually 
simple, the basic relational model had a tremendous impact 
on database management in general and on data models in 
particular. Because of the elegance of the structure and 
the mathematical foundations of the theory of relations, the 
relational model has become the main stay of research and 
development in the database area. The relational data model 
is claimed to be superior to other data models. However.,, 
subjective this observation be, the relational approach has 
definitely achieve d a great goal'^wi bringing together the 
practitioners who implement systems and researchers who 
conceptualize them. The various prototype and commercial 
DBMS that implement relational approach include System 
R [9], INGRES [162], Consequently v/e concentrate only on 
relational data model in our thesis. 

2.5.'^ Query Ljmguag e s ^ 

Data Manipulation Languages (DML) that allow manipulation 
of data stored in database are generally known as query lan- 
guages. They are non-procedural compared to the procedural 

nature of conventional programming languages like PASCAL and 

c-Omtnor) 

FORTRAN, They may have features of programming languages 
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such as assignments, iterative loops and conditional state- 
ments permitting one to refer data as well as to i^jecify some 
manipulation functions such as insertion, deletion, updation 
and query. Since relational data models are based on 
relations (i.e. , set oriented concept), they naturally lend 
themselves to ■ specification operations. The query languages 
use specification operations which may be binary (e.g. , sum, 
product, difference and join) or unary (e.g., selection, 
projection). The salient feature of the query languages is 
their ability to define a new relation based on the existing 
relations using relational algebra or similar (relational 
calculus) type of operations. The new relation is usually 
made available for use as a picture (snapshot) or as a view 
which is an extension of schema. These query languages can 
be classified as* 

(i) Predicate Calculus Language having origin in relational 
calculus concept and based on assertions over a sat of tuples 
of a relation (e.g., QUEL [87], ALPHA [ 4A] ) . 

(ii) Display Oriented Language where user is required to 
fill in blanks on a CRT display to formulate a query (e.g. 

QBE [180]). 

(iii) Algebraic LangiJiage or Mapping Oriented Language which 
is based on operations having relations as operands (e.g., 

SQL [55]). 



Fiither, the query language enables the desired informa- 
tion to be extracted in a relational format by successive 
application of binary operators (e.g. , sum, product, carte- 
sian product, difference and join) or unary operators (e.g., 
complement, selection and projection) on stored database 
relations, treating them as operands. Various query languages 
developed using relational data model concept are QUEL (INGRES) 
[87], QBE [180], SEQUEL [29], SQL [95]. They are briefly 
outlined below. 

QUEL, a language based on relational oalculus was developed 
for INGRES relational system at University of California, Berkeley 

QBE ( Query- By-Example ) , a display oriented query language 
defined by Zloof [180] vjhich runs on INGRES. 

SEQUEL (structured English Query Language) is the modification 
of language SQUARE developed by BOYCE. The modified language 
was developed for System R. 

SQL (structured Query Language) is the modified version of 
SEQUEL. It is an English-keyword, set-oriented relational 
data language. It has been implemented in System R DBMS. It 
is based on the concept of mapping operation. 
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2.6 CONCLUSIONS o 

The survey of literature does indicate the desirability 
of building model management systems that integrate data 
management aspects as well. Such systems alongv/ith a problem 
processor will provide support to a modeller in the entire 
life cycle of the modelling process, and not just in the 
numerical solution of the problem. In our view, numerical 
solution of the linear program constitute but a small, though 
significant, part of the modelling activity. Hence the 
widening of the support to the model builder is likely to be 
of major significance in the modelling research. The work 
reported in this dissertation develops this thesis further 
in the form of an architecture for modelling support and a 
representative system using this architecture. 


CHAPTER III 


MODELLING SYSTEM IMIP 

3.1 INTRODUCTION' 

Optimization modelling has witnessed an impressive 
growth and evolution, as indicated by the literature surveyed in 
the last chapter. In spite of such advances, optimization has 
not received a widespread acceptance, ivhich it rightly deserves. 
Possibly it is due to some of the problems listed below, as 
identified by Geoffrion in [76], These suggest some desirable 
features for a new generation of optimization modelling systems, 
which is the major thrust of this thesis. 

One of the major problems in the acceptance of optimiza- 
tion modelling is the ILdw pro_(^ctivity as perceived by the 
users. It is contributed by different representations - a 
natural representation suitable for managerial communication, 
a modeller's form for the analytic use by the OR/MS professional 
and an algorithmic form that is computer executable. Such multi- 
ple representations demand too many different skills to complete 
even small projects. Matrix generators and the modelling lan- 
guages partly solve this problem by providing convenient auto- 
matic translation from one formi to the other . Another factor 
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contributing to low productivity is the labourious task of 
interfacing models with problem solvers. The commonly used 
MPS Standard [92] for linear programming is ancient and is 
not suitable for modern systems. Finally the available modelling 
systems cater just to one or two phases of the total life cycle 
of modelling such as input data translation and algorithmic 
solution. The phases left out are - requirement design, test- 
ing, revising, maintaining, documenting, explaining, analyzing, 
reporting and evolving the models. Typically such lov/ producti- 
vity leads to poor managerial acceptability. Luckily a number 
of new opportunities, that are being created are potentially 
useful in mitigating many of the problems mentioned above. The 
prominent among them arei 

(a) Desk top computing revolution - this offers a plethora 
of possibilities for optimization modelling in a more 
productive manner and in ways that are acceptable to 
managers. 

(b) Progress in database systems - data management is an 
important activity in most optimization models as most -'Sa. 
real life applications tend to be large. Managing such 
large data manually is a hopelessly difficult job. 

(c) Popularity of spreadsheet modelling - this had enabled the 
managers to get directly involved in modelling, may be 
inadvertently as pointed out by Bodily [23], thereby 
removing the first block in acceptability of models by 
the managers. 


The problems and opportunities enumerated above 
suggest that the evolution of problem processors through 
matrix generators and modelling languages must go several 
steps further in the form of new generation of modelling 
systems with the following features 5, 

(a) independence of model representation and model 
solution with general interface standards to facilitate 
the integration of a variety of solvers. 

(b) extending the scope of the computational support to 
the modeller in all. aspects of modelling. 

(c) integrated data management and adhoc query facilities. 

Keeping in view the points cited above we decided on a 
set of goals for our research, outlined in the next section. 

3.2 RESEARCH GOALS? 

The desirable features of a modelling system, as out- 
lined earlier, represent a possible architecture for a new 
generation of systems that are likely to influence optimization 
modelling in a significant manner. In order to demonstrate 
our thesis we will set out to build an experimental system, here- 
inafter ' referred to as LAMP, incorporating this architecture, 
and illustrate through detailed examples the advants^ges that 
are likely to accrue arising out of such a point of view. No 
attempt is being made to develop a full fledged software of 
the kind that is readily usable. We feel that such an effort 
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calls for an altogether different effort and skill and may 
even be premature at this stage. We need a translation 
system i.e., a modelling language subsystem to translate 
the modeller’s form into an algorithmic form. The modeller’s 
form must be so chosen that it is communicable to the people, 
not necessarily to OR/MS professional, yet easy enoiogh for 
translation. Most of the modelling 1'j.nguages like G.AI-IS [l2l] , ■ 
LPMODEL [ 103 ], XML [66] are still evolving at this stage and 
aim at developing them into powerfifL and independent systems 
of commercial/professional quality software. Since our pur- 
pose is modest and purely of an experimental interest, we 
plan to build a system that is small, elegant and yet of 
reasonable power. Having built a modelling language we 
would like to interface it with an independent solver 
LINDO [ 145 ] that has been in use at Indian Institute of 
Technology, Kanpur for the past few years with a good amount 
of reliability. We do need an interface standard. We are 
not happy with MPS Standard [ 92] which is not well suited for 
query and integration with data management. It appears that 
an alternate view using simple normalized relations, of the 
input and output data -of a linear program would simultaneously 
meet the twin purpose of an elegant interface standard as well 
as a convenient link to the data management function. To 
extend the scope of the system to include data maneigemeiit 
function, we feel that it will be advantageous to use the 
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■well developed technology of data management and query 
languages to do the entire ''what-if" analysis and report 
writing. So we plan to interface our system to an elegant, 
yet powerful DBMS software, viz. UNIFY [ll68] using yet another 
query language SQL [95] which is one of the popifLar members 
of its kind. Another simple reason for using this system 
is its availability at IIT Kanpur. Effort will be taken to 
ensure that the concepts being demo-nstrated are independent 
of the products that are likely to be used i.e., LINDO, UNIFY 
or SQL, so that they remain sufficiently general. Ultimately 
all the units would have been integrated so that the support 
provided, enables the modeller to conduct a truly interactive 
modelling and that the support spans the entire life cycle of 
the modelling process. To summarize, the research goals are§ 

(a) Develop a simple yet powerful modelling language that 
translates the modeller’s form into an algorithmic 
form. 

(b) Develop an interface standard between model language 
system and problem processor system (an alternate to 
MPS System [92]). 

(c) Incorporate data management capabilities using the 
ideas of relational data management. 

(d) Study the use of general purpose querry languages to 
edit, modify and conduct "what- if" analysis of the 
models.' 
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(e) To maintain a modularity of the system so that they 
can be evolvable, communicable, maintainable and 
documentable . 

3.3 RESEARCH BEIIEFITSS 

¥e foresee a tremendous demand for a new generation 
of modelling systems with the architecture outlined earlier. 
Demonstrating a system built on such architecture is likely 
to vindicate our viewpoint that such architecture has 
attractive advantages over the current generation of systems. 
Such a viewpoint is likely to overcome the major problem of 
poor acceptance by user. Specifically, the research tasks 
mentioned earlier are likely to lead to the follov/ing benefits. 

Task (a) outlines yet another modelling language which 
in no way can be claimed to be very superior to many of the 
experimental languages like LPMODEL [103], GAMS [105], M [661. 

It can nevertheless be said that none of the experimental ones 
have a fully satisfactory representation of modellers form 
even with respect to linear programming, litoat is luLtimately 
needed is *a language that oan represent far more general 
models. So any addition can only be welcome at this stage. 

What is significant is that a more general structure of the 
modelling language would evolve with mon. 3 ^ more such experiments. 
In futiJre it is anticipated that with the availability of 
program generators [lOO] , generalized parsers [ 2 ] , compiler- 



compilers, experimenting with newer languages is likely to 
he less expensive. It may be noted here that the modelling 
language being developed would take advantage of the fact that 
many of th-e data that goes into optimization models in fact 
comes from corporate databases. These are by themselves 
expected to be relational in future and the future modelling 
languages would significantly benefit from such an observation. 

Task (b) would enable the unbundling of the problem 
processor from the modelling languages, matrix generators and 
the report writers. In fact many of the modelling systems are 
built around specific problem solvers and such unbundling v/ould 
lead to a happy marriage of powerful problem processors and 
user friendly modelling languages. 

Task (c) would greatly facilitate in the job of having to 
muddle through the vclume of data that is typical of most opti- 
mization models. Use of relational data management provides the 
dual advantages of using the ideas of the well developed tech- 
nology of database as well as an ability to maintain an inde- 
pendence between problem processor, modelling language and 
data management system. 

Task (d) would herald an era of trully interactive 
modelling which would significantly affect both the modelling- 
process and its ultimate acceptance by the user. 
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Task (e) would provide for an evolution capability of 
the model management system. It is definitely likely that 
each of the sub modules woifLd undergo significant advances 
in the coming years due to the developments in conceptual 
mathematics, program generators, query languages, visual 
editors and the user interfaces. We have already outlined 
the possible impact on modelling language design due to deve- 
lopments in the area of program-generation. Developments in 
conceptual mathematics would improve the quality of problem 
processors. The emerging ellipsoid algorithm [84] and 
Karmarkar’ s implementation [lOl] may totally change the 
way linear programs will be solved in future. The future 
query languages would enable a far superior "what- if" analysis 
than what is possible today. Advances in visual editors and 
other graphic interfaces may give the modeller an unprecedented 
interactive modelling capability. Possibly in future an 
intelligent system providing explanation capability could be 
integrated with the system. In essence, the modularity enables 
the user an option of combining the advantages of developments 
in each of the areas without tying him down to any particular ■ 
system. 



CHAPTER IV 


MODELLING LANGUAGE FEATURES OF LAT-IP 

4.1 INTRODUCTIONS 

The previous chapter has outlined the broad objectives 
in the development of a modelling system LAMP at IIT, Kanpur. 

As set out in the earlier chapters the first task is to 
build a modelling language that translates the modeller’s 
form into an algorithmic form. We first take stock of the 
relative strengths and weaknesses of the earlier systems 
outlined in the literature review. These help us to form our 
design goals laid out in the next section. The following 
sections elaborate the features of LAMP as implemented and 
its grammar. A detailed description of the capability of 
LAMP in its job of translation is included in Section 4.3. 

Many real life optimization problems can be modelled as 
linear programming problems. In these situations a modeller 
describes the LP in a s3Tnbolic and readable form using familiar 
algebraic notation for variables, constrednts and objective. 
However, for further processing, the computer algorithm 
requires the model in explicit and computer readable form. 

These two forms of linear program viz. the modeller’s form and 



the algorithmic form, are not much alike and both of these 
forms are essentially required for optimization, as no single 
means of expression could serve as both the forms. Thus any 
real life application of linear optimization requires trans- 
lation from one form to the other form. Translation from the 
modeller’s form to algorithmic form is thus an unavoidable 
task in mathematical programming based models. This process 
of translation has been found to be quite expensive, time 
consuming and difficult on the part of the modeller who plans 

C6^- 

to model real d.ife optimization problems^ Traditionally this 
30b of translation is accomplished by a matrix generator 
software . 

In the traditional approach to translation, the modeller 
first converts a symbolic modeller’s form to a special computer 
program. The execution of that computer program generates a 
linear program in the desired algorithmic form. The inter- 
mediate computer program employs specialized programming 
language and is usually referred to as matrix- generator program. 
Matrix generators offer numerous advantages compared to the 
manual translation of modeller’s form to algorithmic form. The 
principal advantages are [bs]; 

. They provide an elegant way of organizing and 
storing problem data which is reasonably large 
in most real life modelling situations 

. The^?' enforce a uniform scheme for naming rows 
and columns 



. They enable the user to modify model structure or 
model data with much less work. 

However, the common design of matrix generators had 
serious limitations s 

. Matrix generators run in batch mode and require their 
own file structure or environment 

. The algebraic form of model still has to be trans- 
lated by hand to an MG program. Writing this program 
is difficult as it requires strong skill of special 
programming language 

i Large MG programs are hard to follow 

. Devising unique names for rows and columns is often 
awkward 

. They are not readily adapted to nonlinear programming 
situations, because most general nonlinear problems 
could not be expressed in terms of matrix columns. 

In the modern approach to translation the idea is to 
have maximum possible work of translation done by machine 
itself i.e., the modeller should deal with the computer 
directly in modeller’s form using a special kind of one such 
form. This -special modeller’s form should be easy to write 
and understand for the user and easy to read and translate 
for the computer. Central to such an approach is a machine 
readable modelling language that expresses the mathematical 
progrcmi in much the same way as the modeller does i.e., by 
employing a Vv'iriant of algebraic form that is designed to be 
read by a computer system. This machine readable algebraic 
form is referred to as a modelling^ jUingu^e (ML). It differs 
from common algebraic form mainly in employing 
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standardized notation and terminology. A modelling language 
may be treated as a modern replacement for traditional matrix- 
generator language. Essentially both are the ways of describ- 
ing a linear program to a computer system. A modelling 
language makes no reference to the LP matrix. It serves only 
to represent an algebraic form of the model L66j whereas 'a 
matrix-generator language describes a linear program by speci- 
fying all of its non-zero matrix coefficients,. The modelling 
language is not a programming language, where as a matrix- 
generator language is. 

Consequently, a modelling language can make the LP 
modeller’s life easier in a number of waysi 

. It is easier to learn than special purpose 
matrix-generator language, 

. The algebraic description of modelling language 
can serve as a documentation of the model. 

. It can identify constraints and variables by 
familiar method of subscripting. 

. ,It can be easily adapted to nonlinear models. 

The concept of modelling languages has been successfully 
used for other, kinds of modelling as well. However, most of 
the applications of modelling language to linear programming 
have been of smaller scale or have used the concept of a 
modelling language to a limited extent. Further, it is 
generally accepted that modelling languages lead to a more 
reliable modelling scheme often at a lower overall cost [ 6S] . 
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The modern approach of modelling languages has specific 
inherent advantages over traditional approach of matrix 
generators. The general drawbacks of matrix generators were 
mentioned in Chapter II. The advantages of modelling languages 
over matrix generators are outlined below (in the same order). 

Verifiability* 

The major consideration here , is to determine 
whether the modeller’s form correctly represents the reality* 
one should also check v/hether the algorithmic form is a correct 
translation of the modeller’s form. Use of modelling language 
necessitates proper conception of reality and its representa- 
tion which can be treated as debugging of ML representation. 
This is relativel 3 ^ much easier as verification task reduces 
to an item-by-item comparison between modeller’s conception 
and the possible realization from the modelling language. 

Thus ML verification is less costly both in human and computer 
time and promotes ease and reliability. 

Mo di^ i ab i 1 i ty » 

This refers to determining a new modeller’s form 
e3<pressed in the modelling language, when there are changes 
in reality. The modelling language representation can be 
modified directly with ease. Thus linear program modification 
in modelling language system is less costly. The modelling 
language offers similar advantages with respect to 
modifiability as in the case of verifiability. 
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Do ci^entabi.1 it 

This refers to maintaining all relevant information 
pertaining to different forms and their relationships. Modell- 
ing language system avoids extra documentation. Thus the 
documentation task is made simple and easy. 

Indep en^euic e s 

This refers to conceptual dependencies on particular 
algorithmic form. Modelling languages depend less on choioe 
of algorithmic form and therefore modeller need not be incon- 
venienced by the need to know about particular algorithmic 
form. 

Simpl ic ity^ » 

This refers to the need of any intermediate form between 
modeller’s form and algorithmic form. In contrast to matrix 
generators, modelling languages require no intermediate form. 
Modelling languages interact with people through few simple 
forms thereby enabling easier modelling for linear programming 

Further, a modelling language specifies its data symbo- 
lically in some natural and familiar pattern similar to 
modeller’s form. It is not concerned with explicit data and 
enforces distinction between symbolic and explicit data which 
leads to more flexible and convenient management of the data 
for linear programming. The symbolic representation of data 
promotes reliability by serving as a check on the validity of 
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the explicit data. In the modelling language system, the 
ML translator can detect explicit data that are not in con- 
formance with symbolic data and hence any data error has good 
chance of being caught and corrected before an erroneous 
algorithmic form is generated. Modelling languages being 
independent of algorithmic form may employ more flexible 
notation based on subscripted or indexed identifiers for 
naming LP components. Use of indexed identifiers makes 
linear program modelling easier. Modelling languages promote 
row-wise organization based on variable-and- constraint (row- 
wise) form leading to greater flexibility and power,^ The 
evident weakness of modelling languages is that they are hard 
to implement. However, the benefits out-lined above represent 
the significant advantages of using a modelling language. In 
the light of the above advantages several prototype modelling 
languages have been under development, for example, ALPS [170], 
Gms [105], LMC [122], LPMODEL [IO3], MAGIC [52], MIG [147], 
and UIMP [l67] in the recent years. LAJYEP has been developed 
at IIT Kanpur, both as a vehicle for teaching/research and to 
try out our ideas on the synthesis of flexible data and model 
access, which in our view constitute the central theme of the 
decision support system. 
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4.2 DESIGN GOALS 

A modelling language must fulfil the conflicting require 
ments imposed by the demands of the modeller on the one hand 
and the requirements imposed by the computers on the other. 
From the modeller’s view the modelling language should be 
easy to use and understand. It shoiiLd have terminology that 
is convenient to the modeller. The expressions of a modelling 
language need to be powerful and yet flexible. From the view 
point of the computer system, the modelling language should 
be capable of being processed and translated at reasonable 
cost and time. The syntax and semantics of the modelling 
language must be ■unambiguous and simple. The notation and 
symbols must be representable with the standard "ASCII''' 
character set. Representative keywords would replace special 
symbols that have natural meaning to the environment such as 
"sigma" for summation. In order to make the language useful 
to several model builders, it must have a grammar which. is 
simple and yet powerf'ul. As the grammar specifies what 
constructs are acceptable within the language, a simple 
grammar will permit any potential user to learn the language 
with minimal effort in a relatively short period of time. 
Additionally, the grammar should be free from exceptions and 
still be general enough to handle the diverse needs of model 
builders or potential users. 
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Any practical modelling language is a compromise between 
the conflicting requirements imposed by modeller and computer 
system. This compromise can be carried out in many possible 
ways leading to various kinds of modelling languages, with 
greater priority for some specific features. The requirement 
of user convenience can be met ideally by using an existing 
modeller’s form as a modelling language. Through several 
years of use and continuous refinement, common modeller’s 
form have been made convenient and understandable and their 
notation offers the- desired power and flexibility. However, 
these existing modeller’s forms are intended entirely for 
human communication and are neither readable nor translatable 
by foreseeable computer systems.. Like any natural language, 
they are also ambiguous, complex and their meanings are context 
dependent. Moreover, some important notations, such as, summa- 
tion sign and subscripts are even now incompatible with ordi- 
nary computer hardware. 

Nevertheless, an existing modeller’s form is a reasonable 
point to start with for the design of an attractive and work- 
able modelling language* Actually, such a form need only to 
be modified, so that it can be read and processed by the 
computer. Essentially, the variety and oomplexity of the 
existing modeller’s form must be reduced, so that every 
expression has an unambiguous syntax and meaning'^^he choice 
of an underlying structure of the modeller’ s form is an 
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it should be extendable to integer and nonlinear programming 
situations as well. 

(iv) The modelling language should be understandable i.e., 
the s;^nitax and semantic features should represent the language 
in such a way that the user will be able to comprehend it 
easily. 

(v) The modelling language should be natural i.e., model 
can be expressed in terms natural to the domain of the problem. 

(vi) The modelling language system must be readable on any 
interactive terminal with a limited standard key board 
character set. 

(vii) The modelling language system must be sufficiently user 

fr:^ndly. A modem modelling language system should facilitate 
interactive session as well as batch operation. During the 
interactive session a modeller should be able to operate the 
system by typing commands at computer terminal; and the system 
should be designed to send relevant messages and results back 
to the terminal as it runs. A user friendly system shoiild be 
designed to have message display pertaining to specific 
information from user, error messages flashed resulting from 
^improper -user inptrfc and should have necessary recovery 

mechanism. In batch operation the user or modeller can submit 

' the whole set of commands and model information using exter- 
nal files and get result when the entire job is completed. 
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Interactive session affords closer control of a system and 
gives a better feel for what is going on. A modeller can 
watch the model construction by having it report periodically 
or at designed stages on its progress. Interactive session 
is quite useful for model construction phase as the mistakes 
can be corrected as they turn up. Interactive systems conse- 
quently encourage experimentation which is essential to 
successful modelling. Ease of experimentation also makes 
an interactive system easier to leam. The modelling language 
system should concentrate on the construction and development 
of the model rather than on its solution. The modelling 
language system should have sufficient syntactic and semantic 
error analysis capabilities in a way to help the modeller find 
mis specification in his model c 

(viii) The modelling language system should be based on 

concept i.e., dividing the larger task into smaller 
sub tasks that can be treated separately. The modeller should 
not be restricted by any order in which the various components 
of a model need to be v/ritten, apart from the contextual 
naturalness considerations. 

(ix) The modelling language should have abstracti on, capability 
i.e., the system should be capable of expressing nature of the 
problem independent of particular details such as numerical 
constant. 
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(x) The modelling language system should have provision 
for models to be nestedy so that the output of one model may 
be used as input to other model, if required. 

(xi) Any modification to existing modelling language system 
should be simple to implement. 

(xii) The modelling language system should be able to interface 
with existing databases in such a way that not more than a 
minimum of knowledge is required from the modeller. 

(xiii) The modelling language system should be por table, so 
that the model representation is independent of computing 
equipment. 

(xiv) The modelling language system must meet atleast the 
following features with reference to linear programs. 

(a) Symbolic identification of linear program components 
i.e., constraints, variables, R.H.S. and objective. 

The abstract model form of constraint or objective is to 
be modelled in row- wise manner. 

(b) Grouping of variables and constraints i.e., the system 
has to permit variable grouping and a particular type 
of constraint grouping. 

(c) Indexing expression i.e., specifying how a group of 
expression is indexed. 
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(d) Ability to parametrically specify constraints, variables 
i. e., the system has to build abstract constraints with 
parameters such as ''ALPHA'' , indexed coefficient and 
variable. 

(e) Special features: e.g. , system should have provision for 
simple and generalized \jpper bounds, time lag/lead fea- 
tures. Most of the linear programs are likely'' to have 
simple upper bounds and generalized upper bounds. Also, 
some linear programming situation may necessitate the 
incorporation of time lag/lead aspect to model a 

wide variety of real life applications. 

(f) Interface with standard problem solving software for 
linear program and a standard database management 
softwares The modal generated by the modelling langucige 
system needs to be solved for optimization using standard 
problem solving software. Further the result so obtained 
as well as input data need to be utilized for generation 
of related desired information and answering query raised 
by the user. Effective query system necessitates the 
use of a standard database management system software. 

(g) Automatic .generation of coefficients in special cases 
such as generalized and simple upper bounds j In order to 
minimize the coefficient values supplied by the user 
during interactive session or through external file in 



batch operation, the system should generate appropriate 
coefficient values at the run time for some special 
cases of generalized or simple upper bounds. 

(h) Blending constraints? i. e. , the system should have 
provision for blending type constraints commonly 
required for modelling in process industry environment 
where the output of one process becomes the input for 
the next process. 

The above features have been adopted as the design goals 
in our implementation. They were arrived at after extensive 
study of the existing systems under development else\irhere. 

The major emphasis, however, is on proving the ideas and not 
on the development of a software product, which calls for much 
larger investment of a different skill. 

4.3 IMPLEMENTATIONS 

4.3.1 Introjdujstipns 

The modelling language system, LAMP, has been implemented 
on DEC-10 system at IIT Kanpur. Most of the code is written 
in PASCAL [98], The exercise has been primarily to prove 
the ideas, rather than developing .a full fledged software 
product. Hence the diagnostic capabilities of the model are 
limited. However during interactive session or in batch 
operation error and other relevant messages are flashed back 

for modeller’s or user^s help. The system has, however been 

\ 

well tested. 
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The LAMP system uses LINDO [1^5] and GINO [114] as problem 
solving software for linear and nonlinear programs respectively. 
The data management software is the package UlNflFY [168] that 
runs on the UNIX [169] based machine UPTRON 3-32, available at 
IIT Kanpur which is networked to DEC-10 machine. 

The actual model building is in two stages, model struc- 
ture definition and model data definition. In the first stage, 
modeller defines the terminology and then the abstract struc- 
ture of the model using a simple syntax detailed in Section 
4.3.2. In the model data definition phase the data are 
generated by executing the model structure with the data on 
files or provided by modeller during interactive session to 
produce the actual data for interfacing to a problem solving 
software. The format of the generated data are an industry 
standard MPS file [52] and row-wise equation form for input 
as well as a relational format discussed in the next chapter 
for both input and solution values, which we believe would 
be the future generation standard. The salient features of 
implementation are described below. 

4.3.2 The Grammar 8 

The syntax of LAMP has been kept close to the way the 
mathematical programs are typically written by most modellers. 
The summation symbol has been replaced by 'SUM" to enable one 
to use LAMP even v/ith ordinary terminals. The other parts of 
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the modelling language use natural s 3 nnbols. Many of the 
ideas are based on ■ LPMODEL [103 ]s 

The basic building block is an atom, a group of atoms 
constitute a molecule. Molecules are typically used as index 
variables. A t 3 ^ical example woifLd be the molecule ''MONTH" 
consisting of atoms "MAY", "JUNE" and "JULY". The variables, 
constraints and objective function are built out of identi- 
fiers which may be scalar or arrays, indexed over the mole- 
cules, To provide maximum flexibility, LAMP allows different 
molecules to have common atoms and provides automatic genera- 
tion of cartesian products for summation. LAMP also provides 
for variable to appear on right hand side when it is natural 
to modelling. Multi-level indexing of identifiers, multiple 
terms and parametric terns are also permitted by LAITP. The 
values corresponding to coefficient identifiers are stored 
in files (possibly obtained from corporate data base of the 
organization through the use of some database management 
software) or provided by user during interactive session and 
the matrix generated at the time of execution of LAMP. LAMP 
provides for automatic generation of coefficients in the case 
of specially structured constraints such as simple upper 

I 

bounds or generalized upper bounds. 

A compact and complete way to describe the 
modelling language used in LAMP is accomplished by providing 
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its grammar. The grammar is a set of riiles that determines 
■which are the valid constructs in the language. It describes 
the s3/ntax. Moreover, one still needs to e^^plain the meaning 
of the constructs, usually referred to as semantics. For 
user’s familiarity with the grammar, the EBNF (E^ctended 
Backus Naur Fom) syntax for terminology, objective and cons- 
traint — equations and assignments has been provided. Hope- 
fully it is to be used as the key to a quick understanding 
of what constructs are syntactically correct. The detailed 
syntax of the language in Standard EBNF form [9s ] is given 
in Figure 1. 

The modelling language grammar is written using standard 
notation (pattern) of EBNF and contains the following symbols 
knewn as meta- symbols. 




Use 


= is defined to be Separates a phrase name from 

its definition 

I alternatively (or) Separates alternative 

definition of a phrase 

. period or full end of production 

stop 

Additionally, the meta-symbol [... ] refers to the optional 
(zero or one) occurrence of enclosed construct and (...} 
refers to zero_ or more occurrences of enclosed construct. 

The meta- symbol (X|Y) refers to a grouping-; either X or Y, 

The meta-s 3 nnbol "XYZ" refers to the terminal s3mabol XYZ. 
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‘ alternatively 

• end of productiori 

0 or 1 instance of X 
0 or ffiore instances of X 
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•Problem* 

Terminolosy 

Objective 
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£p 1 -constraint •eoln* -CS fI - constraint “eoln'T 4 
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Fig. l: EBIvF Grammar for Lal'IP 
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In the Extended Backus Naur Form (EBNF) the meta- symbol <...> 
enclosing non~terminal symbols have been dropped and any 
s3mibol vrhich does not appear on the left side of a production 
is a terminal symbol. The symbol "eoln" is used to indicate 
the end-of-line feature. 

Every effort has been taken to keep the representation 
as natural as possible i.e., the model can be described in 
terms natural to the domain of the problem. The language is 
based on limited character set usually available on standard 
terminals e.g., (no Greek letters). It permits no subscripts 
and superscripts. It allows algebraic operators "-i-'' for addi- 
tion and '’>^’'for multiplication. Using above described meta- 
symbols as primitives and constructing multi-character names 
for variables, identifiers and parameters, the modelling 
language builds the model as algebraic equation or expression 
which represents the real life problem mder consideration. 

For example, a typical constraint set could be 

SUM[ MONTHI FERTREQ. CROP . MONTH*MONTH 2] < = TFERTREQ. CROP 

indicating that the fertilizer required (FERTREQ) summed over 
all the months must be limited to the total fertilizer 
(TFERTREQ) required for every crop. The coefficients indicat- 
ing the fertilizer requirement come from the indexed identi- 
fi^_ (FERTREQ, CROP. MO NTH) . The molecule name to the left of 
the symbol i.e., "MONTH," represents the summation set. 
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The decision variables are indicated by ’’MONTH?". The actual 
decision variable corresponding to this constraint will be 
all the atoms associated with the molecule name "MONTH'', It 
may be noted that the model structure is independent of data 
i.e., the structure of the constraint set would be independent 
of the number of months considered for planning. 

4.3.3 Say.ent^ ^®?]turess 

The main features of the LAMP system are as follows s 

( i ) Indexe d Constraints ^ 

LAMP allov/s a simple definition of constraints indexed 
by one or more molecules, permitting multi-level indexing 
(upto three levels are permitted in the current implementa- 
tion) . 

Examples 

SW'C CROP iLABORREQ. CROP. MONTH*CRDP ?] <= LABORAVL. MONTH 

This abstract form of the constraint will finally 
generate as many no. of constraint -inequalities as the -number 
of atoms for molecule "MONTH ", labelling each one of them by 
particular atom names corresponding to molecule "MONTH'.' 

(ii) Sum o__f Terms; 

LAMP allows a constraint or a set of constraints to be 
composed of more than one symbolic term. 
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Examples 

SIM[ CROP S WATERREQ. CROP . MONTH*CROP ?] + 

[ LIV STOCKS WATERREQ. LIVSTOCK. MONTH* LIVSTOCK ?] 

<= TOTWATER. MONTH 

This abstract form of the constraint will finally e^spand 
both the terms in row-wise manner, firstly "CROP'' atoms as 
variables and later "LIVSTOCK" atoms as variables indicat- 
ing that the water required summed over all crop atoms and 
water required summed over all livstock atoms must be limited 
to the total water available (TOTWATER. MONTH) for every month. 
The number of constraints generated will be same as the num- 
ber of atoms for molecule "MONTH". 

( iii ) Sm jD f^^ Terms_ with^ Constat Multipliers s 

For parametric analysis one would like to have provision 
for a constant multiplier to be included in the model. LAMP 
is capable of handling such feature. 

Examples 

MAX[ CROP S PRO FIT . CROP* CROP ?] + 

AL,PHA[ LIVSTOCK S PROFIT. LIVSTOCK* LIVSTOCK ?] 

In this abstract form of the constraint "ALPHA" has 
been used as a parameter. The value for this will be provided 
by user at run-time. 
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(iv) Blending Cqns tra inj^^ 

In process industries blending type constraints are 
frequently used to represent process energy or resource 
balance. 

Example; 

SUM[PR0CESS1;HEAT.PR0CESS1*PR0CESS1?] + 

ALPHA[ PR0CESS2 ; HEAT . PR0CESS2*PR0CESS2 ?] 

= ZERO 

(v) Bounds; 

Most mathematical programs contain bounds. Special 
algorithms like bounded variable algorithms exploit this 
structure. LAMP permits for bounds as a special constraint 
and the modeller need not provide the coefficients which are 
automatically generated at run-time. 

Example 

CROP? <= CEILING. CROP 

This abstract form of the constraint will generate a 
set of simple upper bound constraints. The number of cons- 
traints generated will be same as the number of atoms for 
"CROP" molecule. 

( vi ) S imp 1 e _ Summ a tion t 

A good number of constraints in any mathematical program 
is in the form of a simple summation of a set of variables. 

In order to save the unnecessary entry of these coefficients 



69 


in the data file, LAMP permits automatic generation of such 
unit coefficients. 

Examples 

SUM[ CROPS CROP?] <= TOTLAND 

This abstract form of the constraint will generate a 
single constraint with all coefficients as unity for each 
atom of the "CROP" molecule and the summation must be 
limited to land available for "CROP" i.e., (TOTLAND). 

( vi i ) .Special Fe at ure s3_ 

Special features include the generation of combina- 
torial constraints. The cartesian product of indices can 
be indicated in the model structure rather than explicitly 
defining a molecule listing of the elements of the cartesian 
product. 

Examples 

MIN[ ROWS COLUMNS COST. ROW. COLUMN*ROW.COLUr® ?] 

This abstract form of the objective function will 
generate the cartesian product corresponding to ROW, COLUMN 
and using double summation concept write the objective 


function. 
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(viii) Rest ^ic t_e d S -ummat io n s 

Restricted summation can be handled by defining another 
molecule consisting of restricted atoms. 

Example o 

MIX = APPLE, MANGO 

This indicates that molecule "MIX" is defined to have 
atoms as "APPLE*’ and "MANGO". Then the abstract form of the 
constraint 

SUM[MIXiMIX ?] <= CEILMIX 

will generate a single constraint of simple summation type 
i.e., similar to generalized upper bound constraint compris- 
ing of on3.y two variables viz. "APPLE" and "MAI'JGO ", 

(ix) Nonlinear_Termss 

Nonlinear terms can be handled by interactively specify- 
ing the form of nonlinearity of objective function/constraints. 
The current implementation allows simple polynomials and stan- 
dard trigonometric functions only. The variables associated 
with nonlinearity is indicated by double question mark (??) 
instead of single question mark (?). 

Examples; 

MAX[ CROP S WATER. CROP* CROP ?? ] 

This abstract form of the objective function will gene- 
rate the objective function expression after getting the 
nonlinear parameter information from the user at run-time. 
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V^'riable Right Hand _Side» 

Variable right hand side is allowed by LAIiP 
which may sometimes be required for meaningful constraint 
modelling. Variable on the right hand side feature is 
indicated by brace (}) closing instead of bracket (] ) closing 
used in the abstract form of the constraint. 

Examples 

SUI''I[ CROPS WATER. CROP* CROP ?} <= TOTWATSR 

This abstract form will generate constraint expression 
having variable on the right hand side after getting the right 
hand side variable name information from the user at run-time. 

4. A ILLUSTRATIVE EXAMPLE 

4,4,1 Sam ple Pro blem s 

To illustra.te the capability of the LAI'®^ system, we will 
use the following agricaltural planning example adopted from 
[ 103 ] and modified slightly to represent LAMP capabilities. 

A farm manager is planning for the next season consisting 
of the periods May, June and July. The various crops for the 
season under consideration being cotton and onion (cultivation 
crops grown in a field) and apples and oranges (grown in an 
orchard). The land availabilities for the field and the 
orchard are 1850 and 600 units out of the total 2700 units, 
the balance being used for grazing. The labour availability 
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is limited to 5850 \inits. The total availability of water 
is limited to 2O5OOO, 265000 and 275000 units in the months of 
May, June and July respectively, out of which 200000, 260000 
and 270000 units only can be used for crops. The correspond- 
ing availability figures for fertilizer are 4000, 5000 and 
6000 units. The farm is maintaining livestock i.e,, cattle 
and sheep also. The per unit profit contributions per unit 
area of cultivation and similar figures for the livestock 
type are known. There are bounds on the production level of 
the crops and livestock. In addition, a minimum quantity of 
production must be ensured. The per unit requirement of 
water, labour and fertilizer are given. The entire data is 
summarized in Table 1 to Table 7. The farm manager is 
interested in an optimal strategy?- that maximizes his revenue. 

Table 1-' Land Availability 

Field Orchard Total 

1850 600 2700 

Table 2As, Average Unit Labour Table 2B? Labour Availability 
Requirement 

Cotton Onion Apple Orange Total 

2.9 2.7 1.0 1,5 5850 
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Table 3AS: 

unit 

Water Requirement, 




Cotton 

Onion 

Apple Orange Cattle 

Sheep 

May 

65 

- 


0.1 

0.4 

Jme 

80 

60 

50 75 

0.2 

0.5 

July 

90 


64 85 

0.3 

0.6 


Table 3Bs Water Available 
for Crops 

Quantity 

May 200000 

J une 260000 

July 270000 


Table 30 S: Total Water 
Available 

Quantity 

May 205000 
June 265000 
July 275000 


Table 4Ar Unit Fertilizer 
Requirements. 


Table 4B= Fertilizer 

Availability 



""tTottoli” 

"’Onforf' 

' li.ppie "O^ 

range ^ 


"Quahti' 

May 

1 

4 

7 

10 

May 

4000 

June 

2 

5 

8 

11 

June 

5000 

July 

3 

6 

9 

12 

July 

6000 


Table 5» Unit Profit Contributiono 


Cotton Onion Apple Orange Cattle Sheep 
6453 6110 4814 8812 500 


600 
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Table 6As, Bounds for Crops Table 6Bs Bounds for 

Livestock 

Cotton Onion Apple Orange Cattle Sheep 

2000 250 500 800 400 300 

Table 7Ai Yield Data Table 7B§ Minimum Production 

Cotton Onion Apple Orange Quantity 

12 13 14 15 15000 

A . 4 . 2 LA MP F ormulation of the S amp l e , ^r obi emj 

4'he sample problem discussed in sub section 4.4,1 is 

written in LAMP using grammar syntax specified in Figure 1. 

The terminology phase appears in Figure 2 and the abstract 

1 

model structure phase comprising of objective and constraints 
appear in Figure 3= 

I’he various phases of model formulation for the above 
mentioned agricultural planning sample problem is further 
explained in detail. Based on specific requirement (s) of 
the sample problem, Fig. 1 representing terminology phase 
depicts the description of various molecules and identifiers. 
The molecules defined are "MONTH" with "MAY", "JUl'ffi"' and 
"JULY" as its atoms; "CROP" with ''"COTTON", "ONION ", "APPLE " 
and "ORAIJGE" as its atoms; 'ElELD" with "COTTON and 'ONION 
as its atoms; "ORCHARD " with "APPLE" and "ORANGE " as its 





\ \ NOTE : Lines startins with 't' are *Coam»ent^ lines. 

t TERMINOLOGY PHASE 

* MOLECULE 

MONTH^MAY y JUNE f JULY 
CROP=COTTON » ON I ON r APPLE ^ ORANGE 
riELU=COTTONrONION 
ORCHARD=APPLE r ORANGE 
LIUSTOCK=CATTLE» SHEEP 
RESOURCE=LANL!f LABOR > WATER fPERTLZER 

31:== = = = = =: = = = = = =: r. = = =r=^-=rr=.=r=r =, = -=■ = =: =;-=: = =r = = = =r = = ^ = =- = :r = = == = = =:r:=r==r = 

^ IDENTIFIER 

t LAND AVAILABILITY : ( Table~l > 


TOTALAVL* 



FIEL0AVL* 



ORCHAVL* 



* LABOR : 

{ 

Table-2 > 

LABORREQ.CROf't 

( 

Table-2A > 

LABORAyLt 

< 

Table-2B ) 

# WATER : 

( 

Table-2 ) 

WATERREO.CROf. MONTH* 

< 

T3ble-3A > 

UATERREO . LI VSTOCK . MONTHS 

i 

Table-3A > 

TOTWATER. MONTHS 

< 

T3ble-3& ) 

WATERAUL. MONTH* 

( 

T3ble-3C ) 

* FERTLZER : 

( 

Table -4 > 

FERTREO. CROP. MONTHS 

< 

Table-4A ) 

FERTAVL. MONTH* 

( 

Teble-4B ) 

# UNIT PROFIT : 

( 

TabIe-5 > 

PROF IT. CROP* 



PROFIT .LIOSTOCK* 



» bounhs : 

< 

Table-6 ) 

CEIL. CROP* 

< 

Table-6A ) 

CEIL.LiySTOCK* 

< 

Table-6B ) 

# YIELD : 

( 

Tsble-7 ) 

YIELD. CROP* 

< 

T3ble-7A ) 

MINPROD* 

< 

T3ble-7B ) 


Fifi. 21 Agricultural Problem Tei’manology Phase 


3| JT K » as =x a: 5: #= » =: = = as c a: s: sa ss r: sc; ac » t « s= sc SE 3= « a; =: s= ss e= =: = ss es ss = rt ar s= sr C-. ST er ss t: a: = « ts « K »: S 
» rROBLEH STRUCTUF^E 

t OBJECTIVE 

HAX CCROP:pROriT.CROP*CROP?3 + ALPHACLIVSTOCKt PROFIT ♦LIVSTOCKtLIVSTOCK?^ 

t CONSTRAINTS 

t Uateravai lability (Totel ) 

SUHCCROP:WATERREQ.CROP*HONTH3|^CROP?D + clivstock:waterreq*livstock,month*livstoci 
T3<»=TOTWATER.HONTH 

# Labouravailabi lily 

SUHCCROP ; LABORREQ . CROP3*:CROP'?3 <= LABORAVL 

♦ Landavai 3 abi 1 ity 

SUHCCR0P:CR0P73 <= TOIALAVL 
$ riel dlandavai labil ity 

suHr.FiELn:ri£Lirf3 <«■ fieldavl 

» Orchardlandavailabil aly 

SUHC ORCHARD :ORCHARri'?3 <~ 0F;;CHAVL 
t WateravalabilD ty for crof^s 

SUMC CROP : UA7 ERREQ . CROP * MONl H*CROPT3 <> UATERAVL • HONTH 

% Hairamun! yields 

SUMC CROP :Y3 EL D.CROP*CROP?3 HINPROD 

:* Fertilizer consumption 

SUMLCROF:FERTREQ*CROPfMONTH3KCROP?3 <= FERTAVL* MONTH 
t Ceilina on crops 

CROP? CEIL. CROP 

« Ceil ins on livestock 

LIVSTOCK? CEIL.LIVSTOCK 


Fig. 3; Agricultural Problem Model Structure. 
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atoms "LIVSTOCK” with 'tATTLE" and '''SHEEP " as its atoms 
"RESOURCE" with "LAND", "LABOR", "WATER" and "FERTLZER" as 
its atoms. Then the identifiers defined are " TOTALAVL ", 
"FIELDAVL" and "ORCHAVL" to represent land availability 
features based on data from Table 1; "LABORREQ.CROP" and 
"LABORAVL" to represent labour features based on data from 
Table 2k and Table 2B; " WATERREQ. CROP. MONTH ", "WATERREQ. 

LIVSTOCK. MONTH", " TO TWATER. MONTH" and "WATERAVL. MONTH" to 
represent features related with water resource based on 
data from Table 3A, Table 3B and Table 30; "FERTP^EQ. CROP. MONTH", 
and "FERTAVL. MONTH" to represent fertilizer features based 
on data from Table 4A and Table 4B} "PRO FIT. CROP" and 
"PROFIT. LIVSTOCK" to represent unit profit features based 
on Table 5,- " CEIL. CROP " and "CEIL. LIVSTOCK " to represent 
bounds information based on data from Table 6A and Table 6B; 
"YIELD. CROP" and "MINPROD" to represent yield features based 
on data from Table 7A and Table 7B. 

Next in the abstract model structure phase first the 
objective function equation is developed and then the whole 
bunch of constraints representing the real world problem as 
a linear program is developed. However, the constraints 
need not bo in any particular order i.e., the modeller can 
develop the constraints in abstract form in any sequence. In 
order to fulfil the farm mansiger^s strategy of maximizing 
his revenue in the example problem, the LAMP representation 
of objective function will be as. 
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MAX[CR0PSPR0FIT.CR0P*CR0P?] + 

ALPPiA[ LIVSTOCKS PROFIT. LIVSTOCK*LIVSTOCK?] 

The above abstract form representation of the o^oective 
function will generate a single expression considering profit 
contribution coming from crops and livestocks. The actual 
data values for coefficients will be coming from the associated 
identifier data values stored in the system during run-time. 

The value of the parameter, "ALPHA" will be supplied by user 
as 1.0 or any desired value at run-time. Based on above 
information, LAMP system generates the exact expression for 
obiective function. 

Now considering the total water availability as resource 
the LAMP representation of associated restriction in abstract 
form will be as 

SUM[ CROP S WATERREQ. CROP . M0NTH*CR0P ?] ^ 

+ [ LIVST0CK5 WATERREQ. LIVSTOCK. M0NTH*LIVST0CK ?] 

<= TOTWATER. MONTH 

The above abstract form of the constraint will generate 
three inequalities, one corresponding to each month (i.o., "MAY 
"JUNE", "JULY"). The actual coefficient values will be coming 
from the associated identifier data values stored in the 
system during run-time. Similarly, considering the labour 
availability as resource for crops, the LAI/D? representation 
of associated restriction will be as 

SUMLCROPsLABORREQ.CROP-x-CROP?] <= LABORAVL 



The above abstract form representation of constraint 
will generate an inequality with "CROP" atoms (e.g., "COTTON", 
"ONION", "APPLE", " ORAICtE " ) as variables. ^ The actual coeffi- 
cient values will be coming from the associated identifier 
data values stored in the system during run-time. 

Now considering the land availability as resource 
i.e., total land, field land and orchard land as separate 
resource, the LAMP representations of the associated restric- 
tion will be as 

■ SUM[ CROP J CROP?] <= TOTALAVL 

SUM[ FIELDS FIELD ?] <= FIELDAVL 

SUM[ ORCHARDS ORCHARD ?] <= ORCHAVL 

Each of the above abstract form will generate single 
inequality having unity (i.e., 1.0) as all coefficient values,- 
generated by the system at run-time. 

Now considering the water availability as resource 
only for crops, the LAMP representation of associated restric- 
tion in abstract form will be as 

3m[ CROPS WATERREQ. CR0P.M0NTH*CR0P ?] 


<= WATERAVL. MONTH 
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will be coming from the associated identifier data values 
stored in the system during run-time. 

Now considering the minimum yield requirement, the LAMP 
representation of associated restriction in abstract form 
will be as 

SUM[ CROPi YIELD. CR0P*CR0P ?] >= MINPROD 

The above abstract form of the constraint will generate 
an inequality with "CROP" atoms (i,e., "COTTON", "ONION", 

"APPLE", "ORANGE") as variables. The actual coefficient values 
will bo coming from the identifier data values stored in the 
system during run-time. 

Now considering the fertilizer as resource, the LAT^P 
representation of associated restriction in abstract form will 
be as 

SM[ CROP I FTiRTREQ. CROP . M0NTH*CR0P ? ] 

<= FERTAVL. MONTH 

The above abstract form will generate three inequalities, 
one corresponding to each month (i.e., "MAY", "JUN’E", "JULY") 
with "CROP" atoms (i.e., "COTTON", "ONION", "APPLE", "0RA1\IGE") • 

as variables. The actual coefficient values vdll be coming 
from the associated 'identifier data values stored in the system 
during run-time , 

Finally, considering the various bounds e.g. , ceiling 
on crop and ceiling on livestock, the LAMP representation of 
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associated, restrictions in abstract form will be as 

CROP? < = CEIL. CROP 

LIV STOCK? <= CEIL.LIVSTOCK 

Based on the terminology phase definition of molecule 
"CROP" having four atoms (i.e., ” COTTON’' , "ONION", "APPLE", 
"ORANGE") and molecule ’"LIVSTOCK" having two atoms (i.e., 
"CATTLE", "SHEEP") the above abstract forms will generate 
four and two inequalities respectively. Similar to simple 
upper bound constraint, each of the four inequalities will 
be having single variable as atom of "CROP" moleciLLe and 
each of the other two inequalities will be having single 
variable as atom of "LIVSTOCK" molecule. 

Thus the entire formulation for the example problem 
as a linear program is completed. The LAI'IP system generates 
the formulation both in f-IPS format as well as in expanded 
inequality form having entries only corresponding to nonzero 
coefficient values. These appear as Figure 4 and Figure 5 
respectively. 

4.5 FURTHER EXAMPLES^ 

To demonstrate the full capabilities of LA]\'IP to model 
a variety of real life situations, three sample problems 
were selected from Ozon [l3l]- These are "Fomdry Charging 
Problem" representing simple product mix decision; "Gasoline 
Blending Problem" that uses blending concept in a process 
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NAME LINT - GENERATED MPS FILE( MAX) 

ROWS 
N 1 
L 2 
L 3 
L A 
L 5 
L 6 
L 7 
L 8 
L 9 


L 10 



1 11 



G 12 



t 13 



L lA 



L 3 5 



L 16 



L 17 



L 18 



L 19 



L 20 



L 21 



COLUMNS 



con ON 

1 

6453.00006 

COTTON 

2 

65.00000 

COTTON 

3 

80,00000 

COTTON 

A 

90,00000 

COTTON 

5 

2,90000 

COTTON 

6 

1,00000 

COTTON 

7 

1 ,00000 

COTTON 

9 

65,00000 

COTTON 

10 

80,00000 

COTTON 

13 

90,00000 

COTTON 

12 

12,00000 

COTTON 

13 

1,00000 

COTTON 


2,00000 

COTTON 

15 

3,00000 

COT TON- 

16 

1 ,00000 

ON 3 Or' 

1 

6110,00001 

ONION 

3 

60,00000 

On 3Di^’ 

er 

2,69999 

ON I OK 

6 

a ,00000 

ONION' 

7 

1,00000 

ONION 

10 

60,00000 

ONION 

12 

12,99999 

ONION 

13 

4,00000 

ONION 

1^ 

5.00000 

ONION 

15 

6,00000 

ONION 

17 

1,00000 

APPLE 

1 

4814,00001 

APPLE 

3 

50.00000 

APPLE 

A 

63,99999 

APPLE 

5 

1,00000 

APPLE 

6 

1 , ooooc 

APPLE 

8 

1,00000 

APPLE 

10 

50,00000 

APPLE 

11 

63.99999 

APPLE 

12 

14,00000 

APPLE 

13 

7,00000 

APPLE 

lA 

8,00000 

APPLE 

15 

9,00000 

APPLE 

IS 

1,00000 


Jf: 


Fig. 4: 


Model Formulation in MPS Format for 
Agricultural Problem (Contd.). 
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!! NOTE : Lines stsrtins with are 'Con^ment ' lines. 

3| HODEL FORMULATION IN MRS FORMAT for Asriculturel Model • . . < coritinued ) 

^ 


ORANGE 

1 

8812.99996 

ORANGE 

3 

75.0000C 

ORANGE 

A 

85,00000 

ORANGE 

5 

1 ,50000 

ORANGE 

6 

1,00000 

ORANGE 

8 

1,00000 

ORANGE 

10 

75.00000 

ORANGE 

11 

85,00000 

ORANGE 

12 

15,00000 

ORANGE 

13 

10,00000 

ORANGE 

lA 

10,99999 

ORANGE 

15 

12.00000 

ORANGE 

19 

1,00000 

CATTLE 

1 

600,00000 

CATTLE 

2 

0,10000 

CATTLE 

3 

0,20000 

CATTLE 

A 

0,30000 

CATTLE 

20 

1,00000 

SHEEF* 

1 

719,99999 

SHEER 

*:’ 

0,40000 

SHEEP 

3 

0,50000 

SHEEP 

A 

0,60000 

SHEEP 

21 

1,00000 

RHS 

n 

205000.00119 

RHS 

3 

265000,00059 

RHS 


275000,00000 

RHS 

ir 

5850,00002 

RHS 

6 

2699,99998 

RH£: 

7 

1849,99999 

RHE 

8 

600,00000 

RKE" 

c 

200000,00000 

RH£ 

3C 

on poor' _ c- 

F< K S 

11 

269999,99880 

RH£ 

12 

15000,00000 

RHS 

13 

4000.00000 

RHS 

14 

5000,00000 

RHS 

15 

6000,00000 

RHS 

16 

2000,00000 

RHS 

17 

250,00000 

RHS 

18 

500.00000 

RHS 

19 

‘ 800,00000 

RHS 

20 

400,00000 

RHS 

21 

300,00000 


ENHATA 

t 


. ki Mociel Formulation in M’S Format* 
for Agricultural Problem. 


Fig 



H NOTE ; Lir\ef% with '$ 


»re ‘''Coftinent' lirv^s 
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» 

, jjj • ^ 

HAX 6453-0000<SCOTTrN + 6110.000010NI0N + 

4 600 *OOOOOCATTLE + 719. 99999SHEEF' 


4814.00001APPLE + 8812.999960RAN6E 


65.00000COTTON + 

80*OOOOOCOTTON 4 
4 0*20000CATTLE 

<=265000*00009 

90.00000COTTON 4 

4 0.60000SHEEf’ 

2,90000COTTON 4 

<= 5850.00002 

l.OOOOOCOTTON 4 
<= 2699.99998 

1 .OOOOOCOTTON 4 
•1 .OOOOOAPPLE 4 
65. OOOOOCOTTON < 
SO. OOOOOCOTTON 4 

•=••=259999.99940 

90. OOOOOCOTTON 4 

12. OOOOOCOTTON 4 
>= 15000.00000 

1. OOOOOCOTTON 4 
<= 4000.00000 

2. OOOOOCOTTON 4 
<> 5000.00000 

3. OOOOOCOTTON 4 

■;:> 6000.00000 

1 .OOOOOCOTTDN 

1 .0000 DON I ON • ; 

1 .OOOOOAmj 
1 .OOOOOOPANGr 
3 .OOODOC'ATTtr 
3 .OOOOOSHCEP 


O.IOOOOCATTLE 4 

60.000000NION 4 

t C.50000SHEEF 

63.99999APPLE 4 

'>275000.00000 

2.699990NI0N 4 

l.OOOOOONION 4 

l.OOOOOONION <: 

l.OOOOOORANGE <= 

200000.00000 

60.000000NION 4 

63.99999APPLE 4 

12.999990NI0N 4 

4.000000NI0N 4 

C.OOOOOONION 4 

6.000000NION 4 

2000.00000 

250.00000 

500.00000 

800.00000 

400.00000 

300.00000 


0.40000SHEEP <=205000*00119 

50 ♦OOOOOAPPLE 4 75 . OOOOOORAN6E 


85.000000RANGE 

1. OOOOOAPPLE 

1. OOOOOAPPLE 

1849*99999 

600.00000 

50. OOOOOAPPLE 

85.000000RANGE 
14. OOOOOAPPLE 

7. OOOOOAPPLE 

8. OOOOOAPPLE 

9. OOOOOAPPLE 


4 0.30000CATTLE 

4 1 .500000RANGE 

4 l.OOOOOORANGE 

4 75.000000RANGE 

<=269999.99880 
4 15.000000RANGE 

4 lO.OOODOORANGE 

4 10.999990RANGE 

4 12.000000RANGE 


LIST or UAPIAPIEC 

COTTCiN 

GNIDN 

m'lt 

ORAUNL 

CATTLl 

SHlEI'- 

LIST or COrslETRAlNT NAMES 
T OIL* A 7 E RfirA 
TOTWAlEfUUNE 
TOTWATERJUl Y 
LABORAOL 
TOTLANIi 
FlLDLANn 
ORCHLAND 
i^ATERAOLMAY 
WATERAOLJUNE 
UATERAOL JUL Y 
REOYIELP 
fertaml. hay 

FERTAML JUNE 
FERTAUL JULY 
CEIL CUT TON 
ceil ONION 
CEIL APF’LE 
CEIL ORANGE 
CEIL CATTLE 
CEIL SHEEP 

^ ?'??'? 7' 'P7'?'?? 

4 ' 


Fig. 5: Model 'Formulation in Expanded Form for 
^Agricultural Problem. ^ 
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industry j "Bakery Problem" representing product planning wi 
multiple stages. These problems alongwith their LAi'IP formu 
tion are given in Appendix A. 

A ''Help" file to familiarize a novice user is provid 
in Appendix B which contains an interactive session using 
LAMP. 

The detailed documentation listing the function of t 
various modules that constitute the LAMP system forms 
Appendix C, 


CHAPTER V 


STANDARD INTERFACE FOR DaTA MANAGEMENT 

5.1 INTRODUCTIONS 

Traditionally the problem processors were rigid 
computer programs designed for the numerical solution only. 
IjOter they evolved into matrix generators and then modelling 
languages. Many of the matrix generators were built around 
specific mathematical programming systems. It is generally 
true of modelling languages also. In order that the m.odell~ 
ing languagos/matrix generators can interface with problem 
processor, no standards are yet available. Traditionally 
in this area the input data representation employed by IBM^s 
Mattu.'matical Programming Systems Extended [92] has become 
a "de facto " standard. Unfortunately this standard is 
ancient and does not easily lend Itself to further machine 
processing. We propose an alternate fonnalism. using a simpl 
relational vi.'w of the data. This view while acting as a 
standard also helps us significantly in the use of data 
management capabilities for other activities as well. Before 
we discuss the actual representations we take stock of some 
of the concepts of data base in general and relational 
systems in particular. 
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5.2 DATABASE MANAGEMENT SYSTEMS 5 

Data flasa Management Systems (DBMS) usually are not 
thought as modelling systems by the OR/MS community, but they 
are all based on one or another data model [l64] that 
attempts to organize virtually all of the data needs of 
various models. The actual model employed, viz. hierarchical 
network or rela.tional is important in the design of the user 
interface. The* additional requirements of quality, integrity 
security and contr'ol of data, ht'ive far reaching effects on 
th4> overall cost, accessibility and performance of any data 
'b;a5e management system. 

The data base management has the capability s 
, to make an integrated collection of data available 
to a wide variety of users; 

. to provide for quality and integrity of the data; 

. to ensure retention of privacy through security 
measures within the system; 

, to allow centralized control of the data base, 
which is essential for efficient data administra- 
tion; 

. to provide data independence. 

Database management systems have the attractive featu 
of introducing an independence between data structure and 
data manipulation. In the model management concept vre 


A 
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would like to have the structure of the model and the data 
independently kept and linked only at the time of actually 
running the model. This provides us an ability to retrieve 
and update data with an elegance and power that surpass 
qualitative'ly any matrix generator type software currently 
available. The support v/hich a modeller gets in such tasks 
as data validation and manipulation is triily remarkable, 
with the availability of DBMS Software. 

In database tecimology, the data defini tion generally 
consists of statement of the names of elements, their pro- 
perties (e.g., string or numeric type), their relationship 
to other el.emnnts which make up the database. The data defi- 
nition of a specific database is often called as schema . 

The sche ma provides the l ogi cal and physic al structure. The 
logical structure describes the user’s view of data. It 
deals with the named elements and their relationships rather 
than with the' physical implementation. The physical structure 
describes the way the data values are stored within the 
system. It deals with pointers, character representation, 
floating point and integer representation, signed/unsigned 
representation, record blocking and access methods. 

Logical data Independence represents the ability to 
make logical change to the database without significantly 
affecting the programs which access it. Physical data 



89 


inciepencience reliev£=>s user, from providing information on 
details of the structure and allows dealing with different 
structures and/or different access methods. 

The logical structure which describes the user’s 
view is based on data model concepts which allo’ws user to 
define relationship existing among different classes of 
objects. Prominent data models are hierarchical, network, 
and relational as discussed earlier. The general trend in 
datiibaoe management is that users are becoming increasingly- 
oriented toward information content of their data and less 
concerned with its representational details. Such trend 
away from representation details is known as d ata indepen denc e 
Datubasv- management systems using hierarchical or network 
structure rt'proscnt the information by having contents of 
records; the connections between records and the ordering of 
records. User queri^js made to the DBMS are then framed in 
terms which depend on user knowledge of chosen representeition. 
In the relational model, however, information is represented 
by data valvu s only at the user interface. The user queries 
become fret: of any dependence on internal representation and 
may be frc:’.mcd in a high-level non-procedural language. At the 
same time, the system becomes free to choose any physical 
structure' for storage of data and to optimize the; execution 
of a given query. The various types of data models have 
their own tudvantages and disadvcintages. It appears that the 
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relsi'tional model is likely to be the most widely used model 
in the lutiire. It also has an attraction of an elegant 
structure and a strong theoretical foundation. Hence we 
limit ourselves to relational model in our work. 

5.3 RELAQ?IONAI. DATABASE MANAGEMENT SYSTEMS S 

E.F, Codd [43] first suggested relations (tables) 
as a tool for database management in 1970 and defined 
rigorously n-ary relations (i.e., tables having "n" columns 
representing "n" attributes.) in the database context. He 
Gm'f)hasized their advantages for data independence- and 
symmetry of access. Codd’s work introduced concepts which 
set the direction for research in relational database manage- 
ment in later years. The paper [43] defined a data subl^u^e 
as a Sit of facilities, suitable for embedding in a host 
programming language which permits the retrieval of various 
subsets of data from the database. He recommended the first 
order predicatt* calculus, a logical notation to be an appro- 
priate data sub language for n-ary relations. The paper 
also intro due. d a set of operators ("ooin", ‘'projection", 
"selection", etc.) which were later developed into the well- 
known relational algebra. Finally, the paper e3<plored the 
properties of "redundancy" and "consistency of relations 
which laid the ground work for Codd's later theory of 
"normalization". The basic concepts and definitions under- 
lying the rolational data model are summarized below. 
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Mathematically, the term r elati on may be defined 
as® Given sets Dg, (not necessarily distinct), 

^ re lat ion R is a subset of n-tuples each of which has its 
first element from D^, second element from D^, etc. The 
sets are called domains. The number "n" is called the 

decree of R, and the number of tuples in R is called its 
cardinality , 

It is customary to represent a relation as table in 
which each row represents a tuple. In the tabular represen- 
tation of a relation the properties to be maintained areS no 
two rows are identical; the ordering of rows is not signifi- 
cant and the ordering of columns is significant. In a’'rela- 
tion" represented as a table, the number of rows is its 
cardinality and the number of columns is its degree. For 
tabular representation of a relation it is customary to 
name the table and to name each column. The columns (fields) 
of the table are called attributes. In relational theory 
the terms referred as "relation", "tuple” and "attributes" 
arc generally referred also as "table", "row" and "colimns 
(fields) respectively 'for relational applications. The 
individual entries in each tuple are called its components, 

A column or set of columns (attributes) whose values uniquely 
identify t'. rov/ of a relation is a can^idate_ key (generally 
called a key) of the relation. When a relation has more 
than one field as key, it is conventional to designate one 
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as the p,rini§;^y. . kej and the other as the secondary key. The 
term data _ model represents the complete set of relations 
stored in the system. A Schema is a set of declarations 
that describes the data model and a subschema is a set of 
declarations that describes some part of schema available 
to a particular user or a group of users belonging to some 
category. The design of schema and subschema for a database 
is closely related to the concept of normalization which is 
primarily based on features of functional dependencies between 
attributes of a relation. 

Functional dependencies are the main features of 
relational schemes. But it introduces undesirable anamolies 
in relational scheme, i.e., if an attribute value is updated 
in one of the relations, its effect on other relations may 
not be validated oh its own. This fe<iture was first ' recog- 
nized by Codd and he suggested the concept of normalized 
relations to avoid or atleast minimize the effect of above 
anamoly. The underlying principle of normalization is to 
replace the initial bigger schemes by several smaller schemes 
using non-loss decomposition principle as there exists a link 
between functional dependency and decomposition. 

Normalization theory is based on the observation 
that certain collections of relations have better properties 
in an updating environment than the other collections 
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of relations containing the very same 
data do. The normalization theory then provides a strong 
foundation for the design pf relations which have favourable 
update properties. The theory is based on series of normal 
forms (NF) — first (iNF) to third (3NF) and recently to 
fifth normal form (5NF) — which provides successive improve- 
ments in update properties of database and thus minimize 
insertion, update and deletion anamolies. The most v/idely 
known result of normalization theory is third normal form 
often known as 3 '^oyce-Codd Normal Form" (3BCNF). 

The various normal forms can be briefly described as[50] 
Fir st____ No rmal Form s 

A relation is in first normal form (iNF), if every 
component (field) of each tuple (i.e., row of a table) is non i 
decomposable (atomic) i.e., fields must not contain repeat- 
ing groi;^s. 

Secpn^^I^rmal ^im I 

A relation is in second normal form (2NF) if all 
non key attributes (fields) are Mly dependent on keys | 

i.e., every non key field of first normal form be dependent i 
.upon the complete primary key. i 
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Thirci Norml^^ F^ 

A relation is in third normal form (3NF) if all 
non key attributes are directly and fulljf dependent on keys. 
The third normal form (3NF) requires, second normal form 
tables to be decomposed, if a non key field determines value 
of another non ke 3 / field i.e., transitive- de pen denc ies 
should be eliminated. 

F'ourth Normal Form°. 

The fourth nonnal form (4NF) requires that third 
normal form (3NF) tables should not contain two or more 
independent multivalued dependencies. 

Fif th No ra_al_^ F orm 2 

The fifth normal form (5NF) requires that fourth 
normal form (4NF) tables should not be nonloss decomposed 
into three or more smaller tables. [54] 

In context of relational schemes, nonloss decompo- 
' sition means that there is no loss of information due to 
decomposition of a relation into several relations. A non- 
loss decomposition guarantees that the join produces exactly 
the same original relation. The technique of nonloss decom- 
position provides an aid to the relational database design. 
The basic approach consists of starting with some given 
relation, together with a statement of certain constraints 
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in the form of functional dependencies and multi valued 
dependencies. They are successively decomposed to a collec- 
tion of relations that are equivalent to the original rela- 
tion and yet are in some way preferable to it, using the 
constraints to guide the reduction (decomposition) stages. 

Relational schemes giving rise to design of relations 
(tables) have following major advantages. 

Simplici,'^« 

The relational user is presented with a single, 
consistent data structure. User formulates his query strictly 
in terms of information content, without any reference to 
system oriented details. 

According to Date the data independence is 

defined as "immunity of applications to change in storage 
structure and access strategy." The relational model makes 
it possible to eliminate the details of storage structure and 
access strategy from the user interface. 

Data base systems which are based on connections 
between records make some questions easier to ask thcin others 
viz. questions whose structure matches that of the data base. 
Since all information is represented by data values in 
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relations, there is no preferred format for a question at 
the user interface. It should be noted here that the symmetry 
of the data model does not necessarily imply symmetry of the 
associated physical data structures maintained by the system. 

Strong^ Theoretic_al__ ^Foxjndatipn?. 

The relational data model rests on the well developed 
mathematical theory of relations and on the first order pre- 
dicate calculus. This theoretical background makes possible 
the definition of relational completeness, and the rigorous 
study of good data base design (normalization). A language 
is said to be relationally complete,, if any relation derivable 
from the given relations (i.e., the database) by means of 
expression of the relational calculus, can be retrieved using 
that language. 

The other important advantage is the ease of use with i 
which high-level, non-procedural relational languages may be 
defined. Because they are easy to learn and use, high-level | 

languages make databases available to a new class of casual ! 

users who lack the training required by conventional programming 
languages. High-level languages also give the system maxi- j 

mum flexibility to optimize the execution of a given query j 

and to adapt the stored data structures to the changing needs I 
of the user population. The non-procedural approach to | 

language design permits a unified treatment of data definitions! 
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data manipulation and control. Moreover, high-level languages 
make it easy, to define and manipulate views of data which are 
not directly supported by physical structures. Though some of 
the above advantages are common to other data models as well, 
the database management systems based on the relational 
data model approach have been the most extensively researched 
models in the recent years. The reasons are Eiany; the chief 
among them being their elegance, versatility and power. 

5.4 INTERE'ACE DESIGN'. 

In order to achieve the data independence and flexible 
access we first view the input data and output values of 
standard linear programming problem as a set of normalized 
reli-tions. Moreover, to capture all essentifil information 
pertaining to input data these relations have been designed 
accordingly. The following set of eight relations are capable 
of capturing all necessary information related to the input 
data needed in any linear programming problem. 


(i) ivar 

(ii) icon 


(iii) 

(iv) 

(v) 

(vi) 


ivarn - 
iconsn- 
ivarlb - 


the list of variables 

the list of constraints (including the 

objective function as the first constraint. 

the list of variable names 

the list of constraint names 

the lower bounds (if any) 

the upper bounds (ii any) 


ivarub - 
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(vii) 

imat - 

the 

coefficient matrix elements (non- zero 



values only) 


(viii) 

iconsd - 

the 

constraint 

detail (type .and RHS value 


The structure of these 

relations is as follows s 

(i) 

ivar 

9 

(Var_id) 


(ii) 

icon 

0 

9 

(Cons_id) 


(iii) 

ivarn 

% 

(var__id''', 

var_name ) 

(iv) 

iconsn 

0 

(cons_id'^, 

cons_name ) 

(v) 

ivarlb 

a 

(var__id’*’, 

lower_bound) 

(vi) 

ivarub 

% 

(var_id’'', 

upper_bound) 

(vii) 

imat 

0 

(cons_id ' , 

var^id"^, mat_el9ment) 

(viii) 

iconsd 

4" 

(cons_id’'', 

cons_type, rhsvalue) 


NOTES (a) Underlined field (s) constitute the key of the 
relation. 

(b) "+" indicates that the key is linked to a base field. 

This linking with the database field leads to mini- 
mization of deletion and update anamolies in the relational 
data base model. 

The solution values of the linear program can also 
be viev/ed as a set of normalized relations. The following 
set of four rel^-'tions are designed to capture all necessary 
information related to solution of a linear program. 
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(i) 

ovar 

- solution values 

(ii) 

ocon 

constraint values 

(iii) 

objr 

cost range 

(iv) 

orhsr 

- rhs range 


The structure of these relations is as follows & 

(i) ovar i (var^iji’*', solution, relative_cost) 

(ii) ocon S: (cons_id’^, slack, dual“price) 

(iii) objr i (var_id’^, current_cost'*, cost- increase, 

cost-decrease) 

(iv) orhsr 5 (cons_id’^, current_rhs , rhs^increase, 

rhs-decrease) 

The type and format of the fields for both the input 
and solution models are summarized below» 


(a) 

var_id 

e. 

string 

of length 

8 

(b) 

cons_id 


string 

of length 

7 

(c) 

var_name 

p 

% 

string 

of length 

32 

(d) 

cons name 

p. 

string 

of length 

32 


(e) all other fields are numeric of float type (l3,6) 
i.e,, thirteen digits long numbers with six 
digits to the right of the decimal point. 

NOTE: These formats are compatible with I-IPS format [ 92J . 

Some of the queries necessitate storing the results 


of a query for which temporary relations i.e. "ofunct" and 
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"orhfunct" have been incorporated in the schema design of 
interface database. The structure of these relations is as 
follows « 

ofunct S (Kofun^ ovl, ofl^ of 2, of3j of45 of5) 

orhfunct i (Krhfun, rcl, rfl, rf2, rf3, rf4, rf5) 

Using proposed schemes for a set of input relations 
as well as a set of output relations the actual design of 
relational database is done by UInTIFY DBMS package implemented 
on UNIX based machine UPTRON S-32 at IIT Kanpur. Further the 
problem solver LINDO is used to solve the model fonnulation 
done by modelling language component of LAMP. For an introductor 
precise reference to novice users, the specific features of 
the problem solver LINDO is given in Appendix D. The perti- 
nent information about UNIFY package for user acquaintance 

is given in Appendix E. The salient details of the data 

ccftacheq 

manipulation language to UNIFY DBMS package (i.e., 

SQL) is given in Appendix F. 

Once the solution to model formiolation is done by 
LINDO, several sets of interface programs transform the model 
formulation data as well as solution data in a format accep- 
table to the database (i.e., in accordance with schemes pro- 
posed above). Using any appropriate utility to enter the 
data to database, the data entry to relations is achieved. The ; 
schema report listing for input relations as proposed is given : 
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in Figure 6. The schema report listing for i-he output 
associated relations is given in Figure 7. The set of input 
and output relations data generated for agricifLtural planning 
sample problem, as described in Section 4.4,1 is shoT,vn in 
Figure 8 and Figure 9 respectively. Thus the interface 
module has been suitably designed to capture all relevant 
information necessary for a linear programming model. In the 
next chapter we discuss the detailed data analysis capabili- 
ties of LAMP. 



! ! NOTE S Lines startins with are ^Comment' lines 


» 

» INPUT RELATIONS 


SCHEHA REPORTS 
Scheiiia Listing 




RECORO/FIELD 


REF 

TYPE 

LEN 

LONG NAME 

ivar 

100 




var_l i st 

3»cRi var 



STRING 

8 

var_id 

icon 

100 




coris_l ist 

JfrKicon 



STRING 

T 

cons-id 

i varr» 

100 




va rename- list 

3*:ki vsrn 


ki var 

STRING 

8 

var_id 

varnanie 



STRING 

32 

vsr_n3ffie 

iconsn 

100 




cons-ri3ii»e-.list 

i^Kiconn 


kicon 

STRING 

7 

cons.«id 

consnanie 



STRING 

32 

cons-name 

i rib 

50 




var_l owe T -bound 

*kil 


kivsr 

STRING 

8 

vsr-id 

lb 



FLOAT 

136 

lower_bound 

i Vi T ub 

50 




var-UPF er_bound 

»kiu 


ka vsr 

STRING 

8 

var_id 

ub 



FLOAT 

136 

upper -bound 

aeons ci 

1 00 




cofjs-deic i 1 

*kicond 


hi con 

STRING 

7 

CDr.e_id 

tysc 



STRING 

1 

oons-type 

T hvsl 



FLOAT 

136 

rhsvalue 

iniat 

500 




niatr ij; 

3^ kin* at 



COMB 


kin.at 

kiconni 


kicon 

STRING 

7 

cons- id 

ki vsrn. 


ki var 

STRING 

8 

var_3d 

n»at val 



FLOAT 

136 

nic t-elciijorit 


3r 

Note: Starred field (s) indicate (s) k9y(?) ^ 


f r-cl eticns. 


Fig. 6: Schema Listing for Input Relations 
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« !! NOTE : Lines ctertina with are 'Coftment* lines, 

♦ OUTPUT RELATIONS 

SCHEHA REPORTS 
Schema Listina 


* 


RECORD/EIELn 

REF 

TYPE 

LEN 

LONG NAME 

ovs r 

100 



var„ value 

Jitkover 

ki var 

STRING 

8 

va r_id 

oval 


FLOAT 

136 

SD lull on 

rcost 


FLOAT 

136 

relative ..cost 

ocon 

100 



cons^val ue 

Jj^kocon 

kicon 

STRING 

7 

con5_2d 

sval 


FLOAT 

136 

slack 

dp rice 


FLOAT 

136 

dual .price 

obJr 

100 



cosi_ranac 

Jf'kob J 


COHB 


kobw» 

. kobjT 

kivar 

STRING 

e 

var^id 

ccof 


FLOAT 

136 

cur rent. cost 

ocai 


FLOAT 

136 

cost. increase 

ocad 


FLOAT 

136 

cost-decrease 

orhsr 

100 



rhs.T anse 

3^ korhs 


COMB 


korhs 


korhs r 

kicon 

STRING 

7 

corfS-id 

cva] 


FLOAT 

1 36 

cur rent- rhs 

rlivc 1 


FLOAT 

136 

rhs.incT ease 

rhvad 


FLOAT 

136 

rhs- decrease 

of unc t 

IOC 



ot urrrt 

K.C'f UI i 


STRING 

S 

kof un 

ovl 


STRING 

6 

ovi 

of 1 


FLOAT 

136 

ofl 

of 2 


FLOAT 

135 

of2 

of3 


FLOAT 

136 

of 3 

of ^ 


FLOAT 

136 

of A 

of5 


FLOAT 

136 

ofS 

orhf unct 

100 



orhf unct 

3^:krhf un 


STRING 

7 

krhf un 

rc 1 


STRING 

7 

rcl 

rf 1 


FLOAT 

136 

rfl 

rf 2 


FLOAT 

136 

Tf2 

rf 3 


FLOAT 

136 

rf3 

rf4 


FLOAT 

136 

rf-^; 

rfO 


FLOAT 

136 

rf5 


Kotei Starred field (s) indicate (s) key(s) of relations. 


Fig. 7: Schema Listing for Output Kelations 
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!! NOTE t Lines startins with are 'Comment' lines. 

» SAMPLE INPUT RELATIONS FOR AGRICULTURAL MODEL 

* *********** !f»****»*»*»!l»r**»»»**»»»)(<***»»***»»»** 

var-id 


SHEEP 

CATTLE 

ORANGE 

APPLE 

ONION 

CCTTDN 


cons -a d 


21 

20 

19 

30 

1 7 


tA 

lo 

12 

13 

10 

9 

E 


c . -n 

lE „ 1 c J corrS-nanic 

21 

;CEU SHEEP 

20 

JCEIL CPTTLE 

19 

JCEll OPhNGE 

16 

ICEIL AF‘PLE 

17 

JCEIL ONION 

16 

5 CEIL COTTON 

15 

JFERTAVL JULY 

14 

JFERTAUL JUNE 

13 

JFEB'TAUL MAY 

12 

JREOYIELU 

11 

JUATERAULJULY 

10 

lUATERAMLJUNE 

9 

; WATERAULHAY 

8 

JORCHLANIi 

7 

JPIl DLANE 

6 

JTOTLANr 

5 

JLABORAUL 

A 

JTOTUATERJULY 

■7 

J TOTUATERJUNE 

2 

J TOTWATERHAY 


• S; Sample 
Model , 


Fig 


Input Relations for Agricultura 
(Contd.). 
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n ** NOTE J Lines startinS with ere 'Comment' lines. 

t SAHPLE INPUT RELATIONS FOR AGRICULTURAL HOOEL . . . . (continued) 


coris-id I var-id ) niat-eleiuerit 


3 

J ORANGE 

75.00000 

1 

J ORANGE 

8812.99996 

18 

i APPLE 

1.00000 

15 

! APPLE 

9.00000 

14 

: APPLE 

8.00000 

13 

: APPLE 

7.00000 

12 

; APPLE 

14.00000 

11 

APPLE 

63.99999 

10 

I APPLE 

50.00000 

8 

J AF’PLE 

1.00000 

6 

I APPLE 

1.00000 

5 

I APPLE 

1.00000 

A 

1 APPLE 

63.99999 

3 

{APPLE 

50.00000 

1 

{ APPLE 

4814.00013 

17 

{ONION 

1.00000 

15 

{ONION 

6.00000 

14 

lONION 

5.00000 

13 

{ONION 

4.00000 

12 

{ONION 

12.99999 

10 

I ONI ON 

60.00000 

coris- 

idJvcr_id 1 

! niat^element 

7 

1 ONION : 

1.00000 

6 

{ONION 

1 .00000 

5 

lONIOL 

2.6999<=‘ 

3 

{ONION 

60.00000 

1 

{ONION 

6110.00001 

j £ 

JCDTIGN 

1 .00000 

15 

{COTTON 

3.00000 

lA 

{COTTON 

2.00000 

13 

{COTTON 

1.00000 

12 

{COTTON 

12.00000 

13. 

{COTTON 

90.00000 

10 

.‘COTTON 

80.00000 

9 • 

{COTTON 

65.00000 

7 

{COTTON 

1.00000 

£> 

{COTTON 

1.00000 

5 

{COTTON 

2.90000 

A 

{COTTON 

90.00000 

3 

.‘COTTON 

80.00000 

2 

{COTTON 

65.00000 

1 

{COTTON 

6453.00007 


Fig. 8: Sample Input Relations for Agricultural 
Model, 



* H NOTE : Lir.es startina with are 'Co»B,er.t' lines. 

» SAMPLE OUTPUT RELATIONS FOR A6R1CULTURAL MOKL 

« *****»»»»*^**»***»*#»*****.-»»»**»**)|:»*»*»»#*»»»»,i, ■ 


var.^id 

1 solution 

relative-cost 


SHEEP 

; 300*00000! 0*00000 


CATTLE 

! 400,00000 

0.00000 


ORANGE 

! 37*500001 0*00000 


■apple 

J 0,00000 

1795,74990 


ONION 

! 0,00000; 2546,25010 


COTTON 

; 1849*99999 

0,00000 


cons « id I slack! 

due 1-5= rice 


21 

0,00000! 

719.99998 


20 

0*00000; 

600*00000 


19 

763.50000; 

0*00000 


18 

500,00000! 

0*00000 


17 

250*00000! 

0*00000 


16 

150.00002! 

0*00000 


15 

0,00000! 

734.41666 


14 

887.50036: 

0.00000 


13 

1775*00000! 

0.00000 


12 

7762*49981 I 

0.00000 


11 

100312*50268! 

0.00000 


10 

109187.50316! 

0.00000 


9 

79750*00203! 

0.00000 


8 

562*50000! 

0 * 00000 


7 

0*000001 

4249.75014 


6 

812*50000! 

0.00000 


5 

428*74999! 

0,00000 


4 

105012*50327! 

0.00000 


3 

113957*50344 1 

0,00000 


- 

84590*002301 

0*00000 


V c f - 1 Q 

; cut Tcnt^cost 1 cost_incrc3se 1 

cost- deer ease 

sfCEr 

! 719*99998 

999996*99864 1 

719*99996 

CATTs-£ 

! 600,00000 

ooooo^; ^ 99Sc*4 ! 

600.00000 

OK AfvGI 

ESS 3. 00032 

169'99 *00001 ! 

2394*33330 

AF'F'LE 

4814,00013 

1795, 74 990 

999996, 99864 

Or’IOK 

. 6110,0000:. 

2546,25010! 

copooo ppc*£,.^j 

COTTON 

; 6453.00007 

999996,99664 ! 

2546.25010 

cons -id 

cur rent.«rhs 1 

rhs-iricrease ! 

rhs- dec tease 

21 

300.00000 I 

175020*83033; 

300,00000 

20 

400.00000 : 

350041 *66067 ! 

400.00000 

19 

800*00000! 

999998*99864! 

762.50000 

16 

500.00000 ! 

999996*99664; 

500.00000 

17 

250*000001 

999905 ^ 99S£ij i 

250.00000 

16 

2000*00000! 

999996*99864! 

150*00002 

15 

6000*00000! 

96S.1E311 : 

450*00000 

14 

5000 . OOOOC ! 

999995 ♦ 99S64 ; 

8S7. 50036 

13 

4000,000001 

999996*99664! 

1775, 00000 

12 

15000*00000! 

7762 . 49981 ! 

999998.99864 

11 

269999.99861 ! 

999996*99864! 

100312.50268 

10 

259999*999401 

999996*996641 

109187.50316 

9 

200000 * 00000 ; 

999996,99664! 

79750. 002G3 

8 

600 ♦ 00000 ! 

999995*99864! 

562.50000 

7 

1649*99999 ; 

150.000001 

940*90907 

6 

2699.99999 1 

999996*99664! 

812.50000 

5 

5650.00002! 

999990*97664 ! 

428*74999 

4 

275000.00000! 

999996,99864; 

105012 . 50327 

3 

265000 , 00060 * 

999998.99864; 

113957*50344 


2 05000 ♦001191 

9 7 9 7 9 6 * 99864 ! 

84590*00230 




Fig. 9 j Sample Output Relations for Agricultural 
Model. 



CHAPTER VI 


DATA MANAGEMENT ASPECTS OF LAMP 


6.1 INTRODUCTIONS 

Most real life LPP*s tend to be of reasonably large 
size involving several thousands of variables and several 
hundreds of constraints. Obviously, one has to ensure that 
each and every coefficient that goes into the model is correct 
both in its value aid its association with appropriate variable 
and constraint. This is definitely not a trivial issue. The 
early matrix generators used several utilities to perform 
this task. Routines for the above basic task have been incor- 
porated in PERUSE [UO] and sophisticated testing routines to 
reveal common errors have been incorporated, in ANALYZE [82]. 
Substantial portion of mathematical programming software like 
MPSX [ 92 ], LINDO [145] is devoted to the job of data validation. 
Data validation which is the part of model validation ensures 
the exact value of data used in algorithmic form in place of 
coefficients and right-hand- side values in the form of identi-^- 
fiers and parameters of the modeller’s form. 

Modelling languages incorporate distinction between 
symbolic and explicit forms of data and thereby offer more 
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flexible and more convenient management of daba than the 
common matrix-generation language. Symbolic representation 
of data also promotes reliability by serving as a check on 
validity of explicit data. The modelling language translator 
can detect explicit data that are not specified in conformance 
with the modelling language symbolic representation. 

The modeller needs help in the presentation of results 
which again become voluminous. Report-writer programs devoted 
to this task have been appended to the standard mathematical 
programming software. The LP solver generates an optimal 
basis. But the modeller/user wants to kno\\r the optimal acti- 
vities and other solution values. Thus any linear programming 
system needs ways of storing and retrieving both input data 
and solution values, extracting solution data to make readable 
reports. Both the tasks viz. data validation and report writ- 
ing act as heavy overheads on the problem solving software. 
Based on the solution of the model, usually the modaller may 
have some query. In addition, detailed "what if" analyses that 
are mandatory in any modelling activity require an ability to 
modify the data and the structure and re- solve the problem, 
interactively. 

A modelling language provides the modeller with a 
medium to express the model structure to a model manage- 
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meiit system, which in turn generates the detailed model 
data for the problem processor. To support the modeller 
in the interactive editing, report writing and "what if" 
analysis stages we need a similar medium for expressing 
the model manipulation function. We initially planned 
to design a language that provides model manipulation 
capability. A closer look, however, revealed the fact 
that the manipulation of the structure can be handled 
using the model language itself in association with a 
standard text editor. Other manipulations primarily amount 
to data manipulation and the well developed theorjr of 
relational databases and a query language based on a rela- 
tional system should be able- to provide this capability 
directly. Of course, this woxfld mean an ability'’ to inter- 
face modelling language with a query language. The rela- 
tional view of the linear programming problem precisely 
provide such an interface. We the idea by 

interfacing LAMP with a relational system UNIFY [l68j v/hich 
supports a query language SQL L95j. 

It turns out that our conjecture is in fact true, 
as v/e demonstrate it in detail in the following sections. 
Thus we managed to exploit the rich capabilities of the 
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query language without designing another language for model 
manipulation. Additionally the ideas we demonstrate are 
general enough to be of value in other application areas 
as well . 

6.2 Data ANALYSIS! 

6 . 2.1 

A relational view of the input data and solution values 
enablesus to exploit the power of the relational DBMS software 
to assist the analyst in the different aspects- of the modelling 
process. Various kinds of "sensitivity" and "what if" analyses 
can be performed in a flexible manner. Every relational DBMS 
softv/are supports a query language which is non-procedural. 
Non-procedurality allows the analyst/modeller to view the task 
v;ithout getting involved much in the details of how exactly 
the task must be translated into a set of procedures. The actual 
procedure conversion can be conveniently left to the machine, 
thereby peimiitting a meta-level interface between the modeller 
and the machine. Most of the query languages have the property 
of relational completeness i.e., any query of arbitrary com- 
plexity concerning the database can be written with the help i 
of the query languages. Also most query languages sipport 
user friendly interfaces for interactive editing, report I 

writing, data entry, etc. Such an environment facilitates fairly! 
complex analysis, to be performed with ease. 
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UNIFY, a relational database management system software 
which has been implemented for data management aspect uses 
Structured Query Language (SQL). SQL permits "select", 

"from", "where", constructs for simple queries. It further 
allows nesting, arithmetic computations, delete, insertion 
and update features to build desired queries of varj/'ing com- 
plexities* UNIFY also has embedded "SQL by Forms" based on 
the Query- By- Example (QBE) approach. In addition it has a 
listing processor (LSI) and a report processor (RPT) which 
can present and produce formatted reports based on results 
of query as desired by an analyst/user. Typically most of 
the current generation relational DBMS provide similar capa- 
bilities. 

SQL is emerging to be one of the most popular query 
languages. Data analysis for various information related to 
real world problem model can be done using SQL. ¥e illustrate 
this idea in following subsections. For the sake of clarity 
we classify the analysis into three stages viz. , 

(i) Input Data Analysis 

(ii) Solution Report 

(iii) "What-if " Analysis 

6.2,2 .Inpul^ pata_jAnal 

The modeller/analyst may like to verify all possible 
coefficient and right-hand- side values that go into the 
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model as input data. Further, based on them he may like to 
have information pertaining to problem statistics, problem 
summary, simple error checking, consistency checking and sophis- 
ticated checking. Each of them is discussed separately. 

Statistics like the count of variables, count of cons- 
traints of different t 3 rpe, nonzero coefficient count, density 
of the matrix, etc. can be conveniently obtained using SQL, 

Such gross measures provide a preliminary level of check and a 
rough idea of complexity of the numerical solution of the prob- 
lem. Sample query (Qsi) in Figure lO illustrates these features 

In the first query (Qsi.l) the "select" verb uses aggre- 
gate function "couni>" to obtain the total number of records 
(i.e., number of variables) from the input relation var__list 
(ivar). 

Similarly the second query ( Q s 1.2) finds the total 
number of records (i.e., number of constraints) from the input 
relation cons_list (icon). 

In the third query (Qil.3) the "select" verb obtains 
the total number of such records whose constraint t3qDe is less 
than equal to ( "< = " or "L" ) in the input relation cons_ 
detail (iconsd). The "where" clause specifies the required 
condition. 
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» !• NOTE ; Lines stsrtins with '** *re 'Coiiiii.ent ' lines. 

t < 0:i *** Problem stBlistics > 

^ ^ y 

t -C Qtlel *«4 No of vari3bles> 

select count (*> from iver/ 

3K < Q J 1 4 2 ♦ ♦ ♦ Ho of const rsirits> 

select count from icon / 

3^. -C Q : 1 ♦ 3 4 * * No of <> constraints > 

select count (!►) from iconsd where coris-type=^ ' t V 
% -C QJ14-1 4v4Ho of nonzero coef f icients> 

select count (>►:) from a mat / 

-C Q : 1 * 5 . . . No of uriit coef f icients> 

select count ()> ) from imat where imat .. me t_e 1 enicnf -2 / 
t < O: 1,6 *** hatriN density > 

delete of unci./ 

inssri iritc ofuncl (i.cf'uri) J <! 'n.rtder. '// 

update ofur.cl set oil- selecl count(3^) from iniSt; 

whe re kof uri= rwotden^ ' / 

usdcte ofurjct set of2= select countCJ^) f ron; ivar? 
wfiere k.of un~ ' mstoenJ^ ' / 

update ofunct set of 3- select courit from icon? 

whe re kof un= ^ nie tderi3f '' / 

update ofurict set of 4=of i/<Df2*Qf3> 

wh^re k.of uri= "" n.at derj3J "' / 

select kofunycf 1 » of2>of3>of4 from ofunct 
where kof un = "matdenJ^^ / 

Fig. 10: Queries for Problem Statistics. 
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The fourth query (Q»l,4) obtains the total number of 
records from input relation matrix (imat). This will be the 
total number of nonzero coefficients as input- relation matrix 
(imat) initially stores nonzero coefficient values only. 

In the fifth query (Qs 1.5) the "select" verb obtains 
the total number of specific records from input relation matrix 
(imat), using' "where" clause specifying the required condition 
(i.e., only those records for which the coefficient values 
are unity). 

The query set (Qsi.6) uses several queries to find the 
matrix density of LP matrix stored in the data base. In order 
to compute the matrix density the output relation (ofunct) is 
initialized by deleting all its previous records and fields. 

The key (kofun) of relation (ofunct) is set as "matden* " . 

Then the field "ofunct* ofl" for record having key as "matdenst*' 
is set equal to the value obtained from another query block 
which finds the total number of nonzero coefficients in the 
input relation matrix (imat). Similarly the field "ofunct. of2' 
is set equal to total number of variables for an input record 
with key as "matden*". Next query block updates the field 
"ofunct. of3" with a value equal to total number of constraints 
for an input record with key as "matden*". Next querif block 
updates the field "ofunct. of4 " with a value equal to required 
matrix density which is computed using previously stored values 
corresponding to an input record with key as "matden* " . 
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Finally title result is displayed by selecting various fields 
and result from the relation (ofunct) having key as "matden-^ 

Thus Figure 10 illustrates queries representing "Problem 
statistics" features associated with a linear program. 

(ii) 

Sometimes the analyst/modeller may be interested in 
input data summary only. An ordered list (in any specific 
order) of variables, constraints, variable names, constraint 
names, right-hand- sides, bounds, smallest and largest elements 
in matrix, etc. can be obtained to enable a neat summary of 
the problem data. Sample query (Q»2) in Figure 11 illustrates 
these features. 

In particular, in the first query (Qs2.l) the "select" 
verb obtains all the constraint names (cons_name) from input 
relation cons_name_list (iconsn) and displays them in ascending 
order of constraint names. 

In the second query (Q5;2.2) all the fields of input 
relation var__upper__bound (ivarub) is displayed in descending 
order of upper_bound values. 

In the third query (Q5*2.3) the first qiiery block obtains | 
the smallest coefficient value from input relation matrix (imat)j 
and the second query block obtains the largest coefficient i 

value from the same input relation matrix (imat). 
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t NOir : Lines starlins with are ‘'Coti.menl ^ lines. 

-C 0t2 ♦*. Problen suumare > 

3^ < y 

* < Qt 2 *l List of constrsint nenies iri ascending order > 

select cons-nenie 
f T oni irortsn 

or den be cor«s-.rion<e ssc/ 

% < 0:2.2 ... List of bounds in descending order > 

select t 
front ivarub 

order bs upse rebound desc/ 

* ■{ 0:2.3 ...Sn.sllest and largest elenient in matrij-r > 

selec t n.iri (ntat_el en.er»t ) 
f ron in. at 

where n.al — elenient > 0 / 
select rj:ax <iT.st-.e lenient > 
f T or i n.c i 

where fti£t-.elenient > 0 / 




Fig. 11; Queries for Problem Summary. 
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Ihus Figure 11 provides sample queries representing 
"Problem Summary" features associated with a linear program. 

(iii) Simple_J!rrpr 3l®p]iyig/^pnsi_ste:^^^ Checking^ 

Model validation requires model to represent the real 
life problem exactly. The input data values should be properly 
associated with variables with reference to a specific cons- 
traint. Minimal consistency checks are provided by the rela- 
tional model directly. For example, the linking of the key of 
the input relation matrix (imat) with the key (kivar) of 
var_list (ivar) and key (kicon) of cons_list (icon) automati- 
cally ensures that the matrix elements are defined only for 
Vcilid variables and constraints that are already available 
in (i.G., known to) the database. Checking for a variable 
that does not have nonzero coefficient in any constraint and/or 
a constraint with no nonzero coefficient corresponding to any 
variable can provide a simple error check. Such errors easily 
creep in many of the large scale problems due to a variety?- of 
reasons. Also one can easily check for any constraint(s) with 
all zero/negative coefficient with a positive right-hand- side 
(RHS) element , which indicates a serious inconsistency. 

Sample query (Q»3) in Figure 12 illustrates these features. 

In the first query (Q; 3.1) the inner query block first 
obtains the list of variable identifiers (var_id) from input 
relation matrix (imat) for which the coefficient value 
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NOTE : Lines stertins with are 'Coii.nient lines* 

■C QJ3 Simple eTror checkin^! 

^ 3. 

< Oi3*3 *** Checlv for variable with no nonzero msiri;; coefficient > 

select iv3r*v3r-.id from ivar where ivar^var^id '"= 
select imatr,v3r_id from imat where imet *mai_elenieni 0 
-C CJ3*2 *** Check for constraints bavins nc nonzero LHS elements but 
with nonzero RHS Ualues > 

select icor» ♦ cons-idr cons-.type f rhs value from icon>iconsd 
where icon*cons-.id~icorisd . cons-id and rhss’alue !;■ 0 
and iconsd* cofiS^id 
s c 1 ert i niat * cons_ i d f t on- i ms t 

where imat *mst_el emerit 0 and imat*cons_id 


Fig. 12! Queries for Simple Error Checking. 


/ 
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element) is not zero.- Then the outer query selects the 
variable identifiers (var__id) from- input relation var_list 
(ivar) which are not contained (if any) in the list of vari- 
ables obtained from the inner query. Thus the entire query 
block is able to check for a variable with no nonzero matrix 
coefficient. 

In the second query (0^3.2) the inner query block 
obtains from input relation matrix (imat) all those constraint 
identifiers (imat. cons_id) other than objective function, and 
for which the coefficient value(s) (mat_element) is(are) not 
equal to zero. Then the outer query block selects from input 
relations cons_list and cons__detail only those constraint 
identifiers which are not in the set of constraint identifiers 
obtained as the result of inner query block. Thus the inner 
query block selects all constraints other than objective f’unc- 
tion which have coefficients for left-hand- side i.LH3) and then 
checks for non-match with constraint identifiers (cons_id) of 
relation cons_detail having right-hand- side value (rhs value) 
other than zero. In the above manner the query provides simple 
error check for constraints having no nonzero LHS elements but 
with non- zero RHS value. 

Thus Figure 12 provides sample queries representing 
"Simple error checking" features associated with a linear program 



121 


(iv) Sojghisticated^ 

Many of the LP packages provide for a picture clause 
which pictures (displays) elements in a range say (100-999)- 
One can easily get such pictures using SQL. Problem specific 
data checking like the set of variables that use specific 
resource, ■ say "WATER" (in our example agricultural planning 
model), can be obtained. This kind of checking may be quite 
significant for model validation as a quick check. Relatively 
easier checks for simple upper bounds, generalized upper bounds 
can also be made. Pattern matching, say checking for a 
’transportation" type constraint set, can also be obtained. 

Sample query (Q«4) in Figure 13 illustrates these features. 

The first query (Qs4.l) obtains all fields of input 
relation matrix (imat) for which the coefficient values (mat_ 
element) lie between 100 and 999 and displays the result in 
ascending order of fields (var_id) and (cons_id) of relation 
matrix (imat). | 

In the second query (Qj 4.2) the "select' verb obtains } 

variable identifiers (var_id) uniquely from input relations 
matrix (imat) and cons__name_list (iconsn) for which constraint ! 
identifiers are same and constraint name (cons_name) is having j 
a match either with string "WATER*'' or with string M/ATER*'. | 
Thus the above query is able to obtain the list of variables J 
that Use a specific resource, say "WATER' in this case, | 



NOTE : Lines starting with 


are 'Coninient' line^ 


-C QtA *** Sophisticated checkins! > 

^ y 

-C 4^* F'ic'tuTiris the iiiStrij:: in a ranse > 

select fron. inat where iuiat • ntat^element between 100 
arid 99? 

order by injat*var-id asc? imat t coriS-_id asc/ 

< 05^.2 Ueriables that use a specific resource - say WATER > 

select unioue inat ■» var^idTCons-nsnie fron. inist y iconsn 
w^lere imat •coris«id=^iconsn4con5_id and cons^nanie is in 
WATERS' y ' WATER)^' ' >/ 

< QI<4C Sini>’le: Up pet Eiound > 

select iconsn*coris-i df cons-nanie fron. iconsn » in:sl 
where iiuct ♦cons_id=i corisr.* cons_id and i consrs *cons_id 
seleci in.at * coris^id fron. iniat where a n.et ♦ niSt-elenient 
STouF bv icorisn* cons^id 

hrA ii'tLv suf;, ‘ inic t ♦Hic t ^elemerjt ) - 1 / 

< R , ^ Gc; . ’^Ei i ccd Upper Round > 

select icorisn*coriS-id? cons-nanic froni iconsri? iniat 
where inist ♦coriS-id=icon£ri*cons«id and iconsn, coris^id 
select i n.at ♦ cons-id froni imat where inist ^ n.al-elenierst 
SrouF by iconsri4.coris_id 
having sun( in.at ♦n.at^element ) >1/ 

-C QtA.E ♦ • Transportaior. type pattern > 

seller! irnat* var_idr count(2i) fron. iniat 
where injc-t -i‘niet_elerfierit=l arid iniat ♦ cons_id"= ' 1 
S TOUP by iri.ot * var-id / 

seltct inst *cons-idy count (5^) fror., imat 

w’ jer e iniat ♦ n»at—e lenient = !l arid iniat * cons_id ” 1 

£rouF by i roC t , CDns-.i d/ 


Fig. 15 r Queries for Sophisticated Checking 
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« 

In the third query (Qj 4.3) the inner query block obtains 
the matrix (imat) constraint identifiers (cons_id) for which the 
coefficient value (mat_element) is not unity. Then the outer 
query block selects only those constraint identifiers and 
associated constraint names from the join of input relations 
cons_name__list (iconsn) and matrix (imat) which do not match 
with the results of inner query and finally displays after 
grouping them according to constraint identifier for which the 
coefficient value (mat__element) sum is equal to unity only. 

Thus the above quehy detects the simple i^^jper bound situation. 

Similarly, in the fourth query, (Qs4.4) the inner query 
block obtains those matrix (imat) constraint identifiers (cons_id. 
for which the coefficient value (mat_element) is not unity. Then ^ 
the outer query block selects only those constraint identifiers 
and associated constraint names from the join of input relations 
cons__name__list (iconsn) and matrix (imat), which donot match 
with the results of inner query and finally displays after 
grouping them according to constraint identifier for which the 
coefficient value (mat_element) sum is greater than unity. Thus ; 
the above query is able to display the generalized i;ipper bound 
situation. | 

In the last set of two queries (Qs4.5) the first query i 
obtains from irput relation matrix (imat) all those 
variable identifiers ( var id ) for which 
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the coefficieni: value (mat^elemenl:) is equal to unity and 
constraint identifier (cons_id) is other than for objective 
function. Then after grouping according to variable identifier, 
displays the variable identifier alongwith total number of 
such occurrences in that group. The second query obtains all 
those matrix constraint identifiers (imat.cons_id) for which 
the coefficient value (mat__element) is equal to unity and 
constraint identifier (cons_id) is other than for objective 
function. Then after grouping according to constraint identi- 
fier, displays the constraint identifier along with total num- 
ber of such occurrences, in that group. In this way above 
query can detect "transportation" type pattern. 

Thus Figure 13 provides sample queries representing 
"sophisticated chocking" features associated with a linear pro- 
gram. 

6.2.3 Output Analysis 

The analyst/modeller would not stop at model construction 
and input data analysis. He may generally prefer to go for 
solution values and further related analysis based on the 
solution obtained from the problem solver. In particular, 
he may like to have solution analysis or some kind of sophis- 
ticated analysis. 

(i) Solution ^i^alysis 5 

The modeller/analyst may be interested in some simple 
report or partial summary related to solution values e.g., 
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printing of solution values in a specified order, partial 
summary like breakup of profit into broad categories, print- 
ing of constraints in a specified order, say decreasing order 
of shadow prices. Sample query (Qi5) in Figure 14 illustrates 
these features. 

The first query (Q^5.l) obtains the output variable 
identifiers and associated solution values from output relation 
var_value (ovar) for which the solution value is greater than 
zero and finally displays the result in descending order of 
solution values. 

In the second query (Qs5.2) the first query block 
obtains the profit contribution from atoms of the ’’ORCHARD " 
molecule-using aggregate function "sum". This is achieved 
by selecting the solution value from output relation var_value 
(ovar) and profit coefficient value from input relation matrix 
(imat) corresponding to same variable identifier and taking 
product of the two values. The products are added together 
using aggregate function "sum ". Similarly second query block 
obtains the profit contribution coming from the field (i.e., 
"FIELD") molecule atoms (i.e., "COTTON", "ONION"). Thus the 
query displays the profit, contribution from the specified 

type of crops in the current solution. 

Thus Figure 14 illustrates queries representing' "Solu- 
tion analysis" features associated with a linear program. 
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NOTE : Lines stBrtins with are 'Vomierii' lines* 

-C GJ5 **4 Solution An3li:isis > 

^ y 

< CCS*! 4 44 SintFle E'eFort > 

select ovsT*v3T-.id»ovor * solution f r-oni over 
where over + solution > 0 
order bs ove r^solutiori desc / 

< 0t5*2 -4 4 Partial Sumniary • Contribution f ron? Orchard and Field > 

select suntCiniat-niet-elementJ^ovaT -solution) frons ini3t?ovar 
where i mat * var^i d=-ovsr ♦verbid and iniat . cons_id= 1 ' 

arid ov»er*v3r«id is iri <' APPLE^i^ ' ? ' ORANGEJ^ ' >/ 
seleci sunfCintcl + mat-elenient^+iovar -solution) fron. in.st?ovsr 
wliert intat-ver^io^ovar-v^oT^id c'liO in[ic!t40orjs_-i0” i 

end ovar^ver^id is ir. •'/ COTTON*' ' ^ " ONIOMt '> / 
se lsri i f ros- in.i t where iniet - cons-i d = '' 1 

St. led- ^ fX'or,, over / 




Fig. 14! Queries for Solution Analysis 
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( ii ) Sophis ti c cited Ana ly sis » 

The analyst may like to have specialized reports such 
as list of variable identifiers in increasing order of profit 
contribution and the list of binding constraints along with 
the right-hand" side value for each of such constraint identi- 
fiers. Sample query (Qi6) illustrates these features in 
Figure 15. 

The first query (QsS.l) displays the product of coeffi- 
cient value corresponding to objective function constraint 
identifier and a variable identifier from input relation 
matrix (imat) and "solution" value corresponding to some 
variable identifier from output relation var__value (ovar) 
for which the solution value is greater than zero only. The 
result is displayed in default (ascending) order of the 
product value . 

The second query (Qi6.2) selects those constraint 
identifiers for which slack value is zero. This is done by 
joining the relation (ocon) and (iconsd) using constant identi- 
fier (cons_id). In the display the constant identifier 
and rhs value are shown. j 

This Figure 15 illustrates queries representing "sophisti-i 
cated analysis " features associated with a linear program. ; 





3^. M NOTE': Lines, starting with '3*:' are 'Comment' lines. 


t < 016 ... SoF-hists caied Analysis > 

3 ^. < y 

^ < 016.3 ... Variable List ir» increasing order of profit contribution > 


select imet .mat -elementJ^iovsr ♦ solutior* from imatyovar 
where iniat. v3r_id=ovar ♦ var«.j d and imst ♦ cons-id= ' 1 
and over . soluti on >0 / 

H < 016.0 ...F-indinsi constraint with RHS values > 

select ocori . cons-id y iconed. rhs value 
fron: ocoriy icor»sd 

W'lere oeon.con£_ic = iconsd , cons- i d 
arid ccori.slacl- = 0? 
tiTdcr be ocofi coriS_id deec/ 





Fig. 15 i 


Queries for Sophisticated Analysis 
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6.2.4 "V'/hat-if " Analysis » 

Once the solution for the problem is known, the analyst/ 
modeller is further interested to go for several "what-if 
analyses related to problem domain. The major ones are fea- 
sibility oheck, routine sensitivity analysis, 100^ rule, 
simple analysis, revised solution with some perturbation, 
relative ratio of oontribution and effect of tightening/relax- 
ing an inequality. Sample query Qi? illustrates these features 
in Figure 16. Eaoh one of them is discussed below, 

(a) Feasibility^ Che^^^^^ 

In an LP model any initial solution is of much signi- 
ficance to start with. A modeller may be interested in fea- 
sibility oheok of a speoified solution or a perturbed solution, 
i.e., he may be interested to cheok feasibility if some vari- 
ables are increased by certain percentage while some other 
variables are decreased by a certain percentage. This kind of 
feasibility check can also be made. The query (Q»7.l) illus- 
trates this feature in Figure 16. 

The query (Q47.1) displays for each ■ constraint identi- 
fier the detailed information viz. constraint identifier, sum 
of the product of coefficient value and associated variable 
solution value, the constraint type and right-hand- side value 
from relations cons_detail, matrix and var_value. In this 
process care is taken to ensure that constraint identifier 
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< G 7 ♦♦♦ Whet If Analysis > 

■C G;?*! *** Feasibility Check > 

selec 1 iconsd*cor»s_icit suniC imat .n<8t«elenterit3l^over * solution ) r 
coris-tyref rhsvalue from iconsd y iniat r over 
where- iconsd*cor»s_id ~ i»>at*cons-,id end ovar*var_id~ 
imat ♦verbid and iruat . cons-id '1 ' 

S T OUF by inisl . coris^i d/ 

-C QI7*2 *•* Fcoutine Sensitivity Analysis t OutFut in sonie order > 

select suR((ovar*solution5^aurrent_cost > f ron» DVsr»obJr 
where ovar* var_id=obJr ♦vbt _id and ova r .solution > 0/ 
sel ect ovar . vai „idrover .soluiiorif over * solut ion3t:current».c‘Ost 
froRi ovarrobw’T 

where ov3T*vsr_id = obJr*vsr_id 
crder by current--cost desc/ 

< Qi7^Z «*. IDOL Rule I Sinulteneous Chsnses within Ranses > 

■C All vericble obJectiv»e coefficients change by 2% > 

delc^te of ur»ci 
3 ines 0 

St' 3 e ct oh Jr , va r^ id> obw'r * vst _idy cur rent-cost » cost_incre ase » 
CDst-decT ease y curr ent -costJl- 1 *02 f r or- ct-Jr 

into fi/ 

insert inic of unrt < i-of ur. > c vl y of 1 • of 2 y of 3 s cf A • : 
f T on fl-' 

uydett. ofur.rt sei cf 5^ ( of A-cf i ' /cf 2 where <of"-cfl> > 0 / 
undaie ofunct set of 5= (of 4-of 1 >/of 3 where (Df4-ofl) < 0 / 
select 3^ from ofurjct/ 


select sum ( of 5 > from ofunciyovar 
where kofun= ovar*var_id / 

V G: 7*4 *** Simyle Arislysis I- '' 

< ne-letc- i. verictOe set' 'OKIOHJt' £ creste iiPS file > 

lines 0 
separator ' ^ 

select c oriS—t b‘pe y i consd • c ons — i d from icortsd into w2/ 

lines 0 
seFaratbr * * 

select imat * vsr_idy imat * cortE-io’y imat «.iT.st_element from imst 
where in.st . vei _icj "= 'OiaON':*:' into uA/ 
lines 0 

ecFCirator ' ^ ^ , 

select iconsd*con£ — icly rhsval ue from iconsd into wo/ 


Fig. 16« Queries for ''What— if Analysis» 
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3^ ! ? NOTE! * Liri€*i» src ^ CoitiniC’rj't ^ ljr»&s* 

■C 0 J / 4 4*4 Revised Sctluiion with soRie eerturbstiori y 

de3ete ofurict/ 
lines 0 

se led ove r * vs r_i d » ovs r * vs r« i d t ova r * so 2 y 1 1 on » re 1 e t i ve- co si 
f ron; over- irttO f2/ 

insert into ofunct(kofunf ovl ? ofl yof 2) : 
fron. f2/ 

uj-dste ofunct set of^ =• cfl3*’0*97 where kofun is in 
<dOTTON* ^r 'ONION5l^'>/ 

update ofunct set of 4=of 13| 1 ♦ 02 where not kofun is in 
' COTTON:*: " > " ONION:*: ' >/ 
select :* fron ofunct/ 

select iconsd*coris_idrsuni( imet .ast„elenient*of4 ) f 

cons-type t rhsvolue froiii iconsd? iiiist ? over > of unct 
w^^ere iconsd* cori£_id~intot • cons-id snd cvar * ver-.id=inist « vsr_ i 
and kofun ~ in.st*vsr_id and imat * cons-id '1 
cirouF by amsi*cons„id.^ 

< G:7*6 •** Relative ratio of coritribution front crops and livestock 

as function of cost vector > 

< All Basic variable objective coefficiersts chsnse by 2% > 

delete ofunct/ 

ansPTi into ofunct (kofurtfovl fofl yof2fOf3) i 
sealed obJr ♦ vsr-id? objr* vsr_ id? cur rent -cost » 

cost -increase y cost-decrease froni obJr/ 
urdate ofurict set of 4 = 
select ova r 4 soluti on fronj ovarf ofunct 
whr* T e ova r * va r « i d=kof un / 
update ofunct set of 5= 1 *02:tiof l:*of4/ 
i rt?.e rt i rite- ofunct ( kof urt j* ovl f of 1 > of 2 ? of 3 * of 4 ? of S ) * 

< ' r es ul t ^ resu 1 1* ' f 0 ♦ 0 y 0 * 0 »■ 0 ♦ 0 r 0 ♦ 0 > 0 • 0>/ 
update ofunct set of 5= 

St led sunt < of S) fron ofunct 
where t,Df un''- ' result:* ' ? 
w? >e T e kof urt - resul t 7/ 
u:-ddc cfuTiCt set ofl- 

selec'i sufii^ofS) froR* ofunct where Tcf un''- ■ result:* ar.d 
^Dfur> is in dCGTTONf ' y ' ONION* ? 
where kofun^ '’result*^/ 

update ofunct set of2= 

select suni<of5) fron. ofunct where kof un''= ' result* ^ sr»d 
not kofun is in COTTON* " t ^ ONION* •'> ? 
where bofun - ^result*-'/ 

select kofjnyof i yof2yof5?ofl/of5rof2/of5 fron^ ofunct 
where kofun = 'result*''/ 

< C:7*7 .44 ChsnSins the inequalities to eeuality for e set of constraints 

select * fron. iconsd / 

update iconsd set cons-type = 'E' 

whs TO i consd * cons-id is in < ' 5* ' y ' ^* ' ^ /*',•/ 

select * fron iconsd / 


Fig. 16: Queries for " What -If'" Analysis. 
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does not belong to objective function} solution values are 
greater than zero,* constraint identifiers of relation, 
'-'.cons__detail " and "matrix" match and variable identifiers 
of relations "matrix" and "var_value" also match. Thus 
from the display the user can check for the validation/viola— 
tion of feasibility of solution values. 

(b) ^lontins. Sen^tiyity 

The modeller may be interested in some kind of sensi- 
tivity analysis done on routine basis viz. displaying 
output in some order. The query (Qi7>2) illustrates this 
feature in Figure 16. 

In the sample query ( Q. i 7.2 ) the first block 
obtains sum of the product of variable "solution" value and 
associated current_cost from relation "var_value" and 
'"cost_range ". This is conditioned by the following variable 
identifiers of relations "var_value " and " cost_range'’ should 
match, and variable " solution" value is greater then zero. 

The second block of query then selects variable identifiers 
corresponding to var_value, "solution" value and product of 
"solution" value and current_cost from relations var_value 
and cost range. In the process care is taken to ensure that 
variable identifiers of relations var_value and cost_range 
match. Finally, the result is displayed in descending order 
of current cost. 
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(*^) 100^ Rule s 

All the range analysis traditionally is based on 
single change in either objective function coefficient or 
right-hand- side (RHS) value. However, for simultaneous 
change within range in more than one value of either objec- 
tive function coefficient or right-hand- side (RHS) value 
"100'^ Rule" [31] can be tested. The query (Qs7,3) illustrates 
this feature in Figure 16. 

The sample query (Q; 7.3) checks the "100 percent Rule" 
for 2 % increase in basic variables vsilues. In order to test 
this rule the query block deletes the output rela<.tion "ofunct" 
and then initializes the fields of "ofunct" and it sets field 
"of 5 " of relation "ofunct" equal to absolute proportion of 
contribution from each updated variable. The next query dis- 
plays fields of relation "oftinct". Further query block 
obtains the value of summation for all records for which 
the "ofunct" key matches with variable identifier of relation 
var__list. 

A modeller/analyst may like to add or delete one or 
more variable (s) and sometimes prefer to add/delete one or 
more constraint (s). Sample query (Qs7.^) illustrates one 

such situation in Figure 16. Simple analysis such as delete 

, , \ 

a particular variable i.e. , "ONION (e.g,. 


a variable n 
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in the agricultural planning problem described in Sec. 4.4.1) 
from the model formulation. 

In the query ( Q s 7.4 ) the first block obtains 
constraint type (cons_type) and constraint identifier (cons_id) 
information from input relation cons_detail (iconsd) for 
"ROWS" section and stores in file "w2" . Then the second 
block obtains variable identifier (var_id), constraint iden- 
tifier (cons_id) and coefficient value (mat_element) from 
relation matrix (imat) for which variable identifier (var_id) 
donot match with "ONION*" for "C0LIMI\[S" section and stores the 
result in file "w4 " . Next the third block obtains the 
constri-ant identifier (cons_id) and right-hand- side (rhs value) 
information from relation cons_detail (iconsd) and stores the 
result in file "w6. " • Then finally all these exrcernal files 
along with some formatting files are concatenated and processed 
by interface programs to generate anP^PS file for model formu- 
lation without the variable "ONION ", Similarly other simple 
analysis as mentioned for other situations can also be made. 

( e ) Reyi s ed ^^:^tipn_with Some Perturlyatipn> 

A modeller/ analyst may like to analyze the solution 
after some perturbation done by him in some group of variable 
values. For example, with reference to sample problem 
described in Sec. 4.4.1 he may like to decrease the value, 
say by 3 percent for "FIELD" crops (i.e., 


"COTTON" or "ONION") 



135 


and increase the value, say by 2 percent for rest of the 
variables and then check for the feasibility associated 
v/ith present value of variables. Sample query (Q'o7.5) illus- 
trates above aspect in Figure 16. 

In the query (Q57.5) the first block initia3_izes the 
relation "ofunct" by deleting all its previous records. Then 
next block obtains field values from relation var_value and 
stores the result in file "f2" which is then used to insert 
information in relation "ofunct" using next block of query. 
Then a query block updates the field "ofunct. of 4 " content by 
0.97 times for those records having key match with "COTTON*" 
or "ONION*''. Similarly another query block updates "ofunct.of 4 
content by 1.02 times for those records having no key match 
with "COTTON* "and "ONION* ". The next query block simply 
displays the updated information. Finally the last query 
block displays constraint identifier, computed sum of product 
of coefficient values and associated updated solution values, 
constraint t^/pe and right-hand— side value for each constraint 
identifier as described in feasibility check (Q»7.l). In the 
above manner, the "what-if" analysis of this kind can be 
made . 

(f) Perturbation Study of , a_ _Func_tion of_the J'TOblemy | 

A modeller/analyst sometimes may be interested in I 

sensitivity of an ■ objective fundnon which is i 
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derived from the problem structure say a function 
of some right-hand- side values. For example, he may be 
interested in the ratio of overall profit from a group of 
variables to overall profit from another group of variables 
as a function of some data. With reference to example prob- 
lem described in section 4,4.1, he may like to increase the 
objective function coefficient values for variables, say by 
2 percent and then like to obtain the ratio of profit contri- 
bution from "FIELD "crop (i.e., "COTTON*"or "ONION*" ) to 
overall profit and ratio of profit contribution from rest of 
the variables to overall profit. The sample query (Qi7.6) 
illustrates the above aspect in Figure 16. 

The query (Qs7.6) accomplishes above task using several 
blocks of queries in sequence. The first block initializes 
the relation "ofunct" by deleting all its previous records. 
Then second block of query inserts field values for "ofunct " 
relation by obtaining the required field information from 
relation cost_range (objr). The third query block updates 
field "ofunct. of4" by selecting information from relation 
var_^value corresponding to matching variable identifiers. 

Then the fourth query block updates field "ofunct, of 5" by 
setting the value equal to 1.02 times of the product of coeffi- 
cient value and associated solution value. Next the fifth 
block of query inserts a record with "result* " as its key with 
all other field value initialized. 
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Then tho sixth query block initializes the field 
"ofunct.of5" by obtaining the sum of the field (ofunct.of4) 
values for which the key donot match with ’'result* ", Next 
the seventh query block updates the field (ofunct.ofl) by 
obtaining the sum of profit contribution for variable identi- 
fier that match with ’’COTTON*" or "ONION* ", corresponding 
to record with "result*" as key. The eighih. query block 
similarly updates the field (ofunct.ofC) by obtaining the sum 
of profit contribution for variable identifiers that donot 
match with "COTTON* "or "ONION*", corresponding to record 
with "result* " as key. Finally, the last query block dis- 
plays the profit contribution from field crops, profit contri- 
bution from rest of the variables, overall profit, ratio of 
fi€?ld crop contribution to overall profit, ratio of rest of 
variable contribution to overall profit. 

Thus the above query (Q<7.6) in Figure 16 provide the 
information of relative ratio of profit contribution to over- 
all profit contribution. 

(g) Tightening or Relaxing an^Inequ 

The modeller sometimes may like to tighten or relax 
one or more inequality constraint (s) due to restrictions or 
changes in availability of some specific resource. He may 
like to have analysis of the model solution in light of 
recent or likely changes. Sample query (Q*7»7) illustrates 
this aspect in Figure 16. 
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In the query (Q»7.7) the first query displays all 
fields of relation cons_detaii (iconsn). The next query 
block updates all "cons__type’' of relation cons__detail (iconsd) 
to equality ( E ) i,e., tightens the constraint inequality 
corresponding to specific constraint identifiers (e.g., ”5*", 
"6*", "7*" ). The last query again displays the fields of 
relation cons_detail to illustrate the modification done. 

Thus all the sample queries illustrated in Figure 16 
provide a wide range of "what- if " analysis a modeller can have 
for a linear programming model. 

Further, all the queries together demonstrate the 
various data management capabilities of LAMP using the rela- 
tional format as proposed in our thesis. 

The queries cited above are purely indicative of the 
capabilities of SQL like data manipulation languages and by 
no means exhaustive. The richness of the queries that can 
be constructed are only limited to the modeller's innovative 
capabilities. The queries are not limited to SQL language 
alone. Many of the relational database management system 
do support an SQL like language with minor syntactic diffe- 
rences. The ideas illustrated do apply to a more general 
situation as well. This way we are able to take advantage 
of the well developed theory of relational databases without 
we having to write a separate data manipulation language. 



CHAPTER VII 


SUMMARY, CONCLUSIONS AND RECOMMENDATIONS 

7.1 SUMMARY OF WORKS 

Our moU-elling system LAMP accomplishes to a large 
extent, the objectives we had set out for ourselves in 
Chapter III, LAMP provides an environment in which an 
optimization modeller can describe the model structure, 
obtain the solution of the model, view the resiLLts, write 
reports, perform sensitivity analysis, change parameters 
and re- solve the problem. Almost all these tasks can be 
accomplished in an interactive manner using a medium v^hich 
is natural to the environment. The implementation is 
achieved using a model specification language to represent 
the structure and a model manipixLation language to manipu- 
late the structure and the data. The model specification 
language is specially designed as part of this thesis, while 
the model manipulation is accomplished using a standard 
query language. To enable the use of a query language, an 
interface between the problem processor and the model lan- 
guage is also developed in this thesis. Such an interface 
also introduces an attractive independence between problem 
processor and modelling languages. In shoht an integrated 
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system to support an optimization modeller in all the phases 
of the modelling life cycle has been developed. 

7.2 CONTRIBUTIONSs 

The major contributions of this thesis, in our opinion 
are as follows • 

(a) Demonstrating the feasibility of an integrated system 
to support optimization modelling 

(b) Development of a modelling language which is simple . 

to learn, powerful enough to model a variety of situations 
. and yet keep close resemblance to the natural v/ay in which 
-C. modellers perceive the model. 

(c) Outline a possible interface structure betvreen problem 
processors and modelling languages permitting one "fco 
exploit the combined advantages of independent develop- 
ments in these areas. 

(d) Exploit the powerful capabilities of relational 
algebraic query languages to permit a variety of 
'"what-if analysis to be performed. 

7.3 LIMITATIONS^ 

Since our primary aim was to prove the ideas, our 
implementation is far from perfect. We have not included 
efficiency considerations in the implementation, which we 
plan to look into in the near future. Also we have limited 
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ourselves to optimization modelling, even though we would 
very much like to enhance the scope to several other related 
techniques as well. Since, even the extension to general 
nonlinear programming situation is not very simple, exten- 
sion to capture other modelling situations does appear to 
be reasonably hard. 

7.4 RECOMMENDATIONS FOR FURTHER WORKS 

Any work of this nature in this area is bound to open 
up several new ideas that can be taken up for further work. 
Specifically we feel that the following ones are the most 
promising ones, with a likelihood of significantly changing 
the modelling scenarios 

(a) Extension to general modelling situations as has 
been recently proposed by Geoff rion [76] 

(b) Providing explanation capability to the model systems 
in the line of recent work by Greenberg [83] 

(c) Use of pattern recognition techniques to create a 
family of Intelligent Modelling Systems. 

(d) Use of Program Generators to assist the task of the 
design of modelling languages. 
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APPENDIX A 


FURTHER EXAMPLES 

FOUNDRY CHARGING PROBLEMS [13i3j 

A foundry can use four different kinds ox scrap 
alloys of various composition as raw materials to produce a 
special casting, vdiich will be called here, "cast-A". 

Table A— 1 and Table A-2 summarize the chemical congjound, the 
cost of raw materials Including the melting cost, and the 
chemical compositions of cast-A to be produced. 

Table A-ls Chemical Compound and Cost of Raw Materials. 


Raw Material 

Chemical Compound in 
Aluminium Silicon 

_Percent 

""Orarbon 

Cost/ 
xmit ■ 

Alloy-1 

5.0 

3.0 

4.0 

50.0 

Alloy- 2 

7.0 

6.0 

5.0 

70.0 

Alloy- 3 

2.0 

1.0 

3.0 

60.0 

Alloy-4 

1.0 

2.0 

1.0 

40,0 


Table A-2S Chemical Specification of Cast-A to be produced. 


Chemical Atleast Atmost 

Compound in percent in percent 


Aluminium 

Silicon 

Carbon 


3.0 

2.0 

3.0 


6.0 

4.5 

6.0 



A-2 

• The foundry has a limited supply of Alloy-2 at a level 
of 400 units and of Alloy-4 at a level of 200 units. The 
management of the foundry wishes to determine >±iich alloys 
in what quantities (units) should be included in a 1000 
units charge so that they can minimize the raw material 
cost for producing "Cast-A". The different raw materials 
availability and total charge required are summarized in 
Table A-3 below. 

Table Raw Material Availability and Total Charge 

in Units. 

Alloy- 1 

Alloy- 2 400.0 

Alloy- 3 

Alloy-4 200.0 

Total charge for 

"Cast- A" 1000.0 

Tlie LAMP formixLation for the above "Poundiy Charging 
Problem"is given in Figure A.l and Figure A, 2'. 

GASOLINE BLENDING PROBLEM [l3l] s' 

An oil company produces three types of crude oil 
components — components 1, 2 and 3 ~ with the specifications 
shown in Table A-4 below. 



|c n NOTE : Lanes stertinjs with 't' ere 'Commeni" lines* 

J|J J- Jg JC S ae « » « w * w » ® ® * * “^^^ * * ®== ~ ~ sc =s =: = ss as 5E =: s= sr K 5S a ss- rs s= Si Si sr ST sr ar =. 

3|C terhinology phase 

t HOLECULE 


RAWHAT^ALI r AL2»AL3f AL4 
COHr’OUNi:»=AL f SI »C 
RAWB0UNP=AL2f AL4 

31; lliENTiriER 

* RAWHA7ERIAL COST : 


Table A-1 > 


COST*RAUHATi 


31 COMPOSITION FACTOR t 

COMPOSl *RAOMAT *tOMP0UNriS 
^ MINIMUM RIQUIREMENT J 

ATLEAST .COMF OUNIit 
31 maximum requirement ; 

ATMOST *COMF OUNDf 

3^ TOTALCHARGE OF MELTING i 

TOTMELTt 

t BOUNUS : 

CEILINetRAUBOUNB* 


( Table A-1 > 


( Table A-2 ) 


( Table A-2 ) 


( Table A-3 > 


< Table A-3 ) 


: "Foxmdry Problem" Terminology Phase 


Fig. A.l 
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$ OBJECTIVE 

HINCRAWMAT : COST * RAWMAT*RAWMAT?3 

3*: CONSTRAINTS 

t Hi ni muni Constituent Reauirement 

SUH t R AOH AT : COMPOSE . RAWMAT * COMPOUND*RAUMAT?3.>=ATLEAST ♦ COMPOUND 

* Total melt Reauirement 
SUMCRAWhAl :RAJMA*Tr3 = TOTHELT 

$ H^’;;iniyn; Corisiituent Requirement 

SUHC RAWHAT t COMPOSE ^ RAWMAT * C0MP0UND*RAWMAT?3>=^ ATMOST * COMPOUND 
t Ceil ins* on Rewniaterial 

RAWfOUND ? <« CEILING *RAWBOUND 
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Foiindry Problem" Model Structure 



Table A~4*; Crude Oil Component Specifications. 


Component 

I' erfo nuance" 

"Vapour Pressure’ 

,_,(lb/inch2_) _ 

” Production 

- JPPi? 

1 

110.0 

10.5 

40.0 

2 

100.0 

5.0 

60.0 

3 

90.. 0 

12.0 

80.0 


The company blends these, components to obtain 
gasol ine- A and g.aji3line-;;B with following specifications J 

1. 'J^'he minimum acceptable performance number of gasoline-A 
is 90 and of gasoline-B is 100. The performance number of 
each kind of gasoline is estimated by the weighted average 

of the performance numbers of the component blended, 

2, The maximum acceptable vapour pressure of gasoline-A is 
12 Ib/inch^ and of gasoline-B is 7 Ib/inch^. 

The vapour pressure of each kind of gasoline is esti- 
mated by the weighted average of the vapour pressures of the 
component blended. 

How should the company blend the three components to 
produce gasoline A and gasoline B such that total daily 
profit is maximized. Components 1,2 and 3 are produced at 
the re quired levels of 40, 60 and 80 units per day respectively 
so that the corresponding requirement constraints are binding 
constrain'fcs with no slack. At present gasoline A sells at a 
profit of 5 per unit and B at 8 per unit. 



below. 


Gasoline features required are summarized in Table A-5 


Table k~^x Gasoline Features Requirement. 


Type 

Unit 

Profit 

Performance Number 
(minimum) 

Vapour Pressure 
(maximum) 
lb/ inch 2 



-4-.VA * ... 4-^. ^ . -W . . . . 


A 

5.0 

90.0 

12.0 

B 

8.0 

100.0 

7.0 


The LAMP formulation for the above Gasoline Blending 
Problem is given in Figure A . 3 and Figure A, 4. 

PRODUCT-MIX PROBLEM IN A BAKERY [l3l]i 

Delight Bread and Bun Co. (DBB) employs two parallel 
baking lines, one for bread products and one for bun products4 
Each line is independent of the other, although most of the 
baking operations with in the facility are similar in nature. 
The study was initiated by the management with the objective 
of determining the amount of each of three types of bread 
( 1.5 lb. white btead, 1,5 lb. wheat bread, and 1.0 lb. white 
bread) and two t 3 rpes of buns (hamburger and hot dog bums) to 
be produced in order to maximize the profit. Both of these 
products are subject to constraints imposed by the capacities 
of individual machines in the production lines and the consu- 
mer demand for the products. Based on the forecast information 





t ! ! NOTE t Lines startina with are 'Coaaent' lines. 

R=ZEtt:eff:»iEBlBBnK:K9£ttsxEz»SEae»a.x:=sssKs;KKc:seBscs£S:ser.e£:ssscs!£:=CKE£S£ 

TERMINOLOGY PHASE 
MOLECULE 


CRUPETYPE=l»2r3 

GASOLlNE'ArE 

GASA^Al rA2f A3 

GASB=BltB2»B3 

CRUra=Al>Bl 

CRUI.i2=A2fB2 

CRUIi3 = A3rB3 


IDEKTIFIER 

» UNIT PkOFlI : 

PROFIT.GASA* 

PROFIT.GASI!* 

» PERFORMANCE FACTOR *. 


PERFFACT .GASA* 

PERF’FACT.GASP* 

» Perfornisrict' Number Reouired : 

ORAJ 

ORi 1 

:( Vyfbut fietuuT'fc Fsctoi 

UPFACI -GASA* 


VFFAC7 .GAEB* 

Maximum Valour Pressure 

MAVPGASAi 

MAUPGASBt 

* Bail a Production 


IipRDIiL 1« 

IiPF<0IiL.2* 

OF R0IiL.3f 

3^ F'c*f f orrtt^rice 

BPFGASAi 

BFTGASBi 

* Mt3FOUT j^res 

BMF’GASAf 

BVf'GASBU 

3» Unit Factor 

UNITF ACT .CASAS 
UHIIFAul .GASPS 


Pactor Belarice 
sure balance 


( Table A-5 > 


( Table A-4 ) 


< Table A-5 ) 


(, Table A-A ■' 


( Table A-5 ) 


< Table A-4 ) 


Elending" Terminology Phase. 


Fig. A. 3 


"Gasoline 
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* PROBLEM STRUCTURE 

3 |C K s: a:, at K a « at aaa a; r as c saeas at as !s: 3 :asssr, 5 =ss=:ss=rsc=; carrssacacarsracsara-srsr^ssaaaracaracrraaccsascars: 
t OBJECTIVE 

MAXCGASA:PROFIT*GASA 3 ^«GASA ?3 + rGASB:PROFITeGi^SB 3 l^GASB ?3 

* CONSTRAINTS 

* Octane Number ReQuirement for Gasoline-A 

SUMi:GASA;PERrFACTeGASA3kGASA?3 + ALPHAi:GASA:UNITFACT,GASA)f:GASAT3::-=^BPFGASA 

* Octaf»e Number ReQuirement for Gasoline-B 

SUMCGASB:P£RFFACT.GASB:4iGASB?3+ALPHACGASB:UNITFAC7*GASB*GASB?3>=-BPF6ASB 

* Vaf^-our F'ressure ReQuirement for Gasoline-A 

SUMC GASA:MPF ACT e GASAJ^ G ASA? 3+ ALPHA CGASA: UNI TRACT ♦GASA*GASA?3<~BUPGASA 


* VeHOUT F'ressure ReQuirement for Gaeoline-B 

SUhl GASP :UF'r ACT. GASB)^GASBT34ALPHALGASB:UNITFACT,CA3B>i:GASr:?3<=^BUPGASP 


t Bail*:^ eroduction of Crudl 

suMCCRura :CRUU1'P3 - upRonLi 
t Bsxly production of Crud2 

SUMrCRUIi2:CRUB2?3 = IiPR0riL2 
3|c Bailw production of Crud3 

SUMCCRUr»3;CRUX»3?3 - BPR0DL3 


Fig . A. 4 


"Gasoline Blending" Model Structure 



the estimated weekly bread and bun demand are as follows i 
}feite _brej^^ 

This is a stable product whose minimum should be greater 
than or equal to 280000 loaves per week. Maximum should be 
limited to 300000 loaves per week. 

Wheat Bread .^l,._5,..lb2= 

l^tieat bread is not as popular as white bread and is 
produced mainly to demonstrate a complete bread product line. 

A maximum production rate of 120000 loaves per week is consi- 
dered to be realistic. 

This smaller losf of white bread is not as popifLar 
as the larger loaf (1.5 lb) and hence the maximum demand is 
expected to be at a level of 40000 loaves per week. 

Hpjb Dpg 

The maximum demand constraint is 33000 packages per 
week, the minimum demand is 15000 packages per week. 

fiamjDur^OT 

The maximum output constraint is 80000 packs per week, 
the mtolmum output is restricted to 20000 packs per week. 

The yearly profit on sales figure are shown in Tahle A^6. 



A-10 


Table Ar-6"» Yearly Profit on Sales. 


Product 

' " ^ ' Profit ' 
Cent per product 

Dollars per 
10000^ 

1.5 lb, white bread 

5 

500 

1,5 lb. wheat bread 

4.5 

450 

1 lb. white bread 

3.5 

350 

Hot dog buns 

5 

400 

Hamburger Buns 

4 

400 


The first group of operations performed in the pro- 
duction of tread (blending, dough formulation, mixing and 
fermentation) are best grouped together as one operation 
because of their inter-relationships and because their 
capacities are difficult to isolate. Thus, all processes 
performed by these machines will be referred to as Sta^_ 1 
of the production. In like manner, the dividing/rounding, 
overhead proofer, molder and proofer machines are identified 
as sta^e 2. Stage 3 contains the oven, cooler and slicing and 
bagging machines. The definition of these three stages is 
also applicable to the two bun processes. A capacity unit 
in hours required to produce lOOOO loans of bread and lOOOO 
packages of buns was found a convenient capacity measure to 
be used in formulating the machine capacity constraints. The 
capacity requirements of major stages of production is shown 



A-11 


in Table A-7 below. 

Table A-7S Capacity Requirement in Hours per lOOGO Units. 


Product 

Stage 1 

Stage 2 

Stage 

1.5 lb. White Bread 

4.3 

1*2 

133 

1.5 lb. V>/heat Bread 

4.3 

1.2 

2.0 

1 lb. White Bread 

2.9 

1.2 

1.3 

Hot Dog Buns 

9.0 

2.6 

4.0 

Hamburger Buns 

11.2 

2.6 

4.2 


The times shown include the downtime allowance required 

for maintenance, cleaning, change over from one kind of product 

to the other on each line loading and unloading activities. 

The capacities available for each line and each stage for a 

three shift work force is shown in Table A*-8 below. 

Table A-8S Available Capacity for Each Line in Hours. 

Product Stage 1 Stage 2 Stage 3 

Bread 135 153 151 

Bun 150 135 150 

Using above information the management wishes to 
determine the best product mix for the company. 

The LAMP formulation for the above product mix problem 
is given in Figure A. 5 and Figure A. 6. 



* ! ! NOTE i Lines startina with are 'Coament'' lines. 

a TERMINOLOGY PHASE 

» MOLECULE 

BREAH'XI tX2fX3 


BUN=X4rX5 
STAGE=1 F 2f3 

* HiENTIFIER 

t UNIT PROFIT 

PROFIT.BREAli* 

PROF IT. BUN* 



( Tsble A-6 > 


» CAPACITY REOUIREMENT I 

REG. BREAI .STAGE* 

KEC.'. BUN. stage* 

n available capacity ; 

AULBREAI .STAGES* 
AVLBUN.STAGES* 

a BOUNBS : 

UPBOUNB.BREAIi* 
LOUBOUKB.BREAIiS 
UPHOUNI'.BUN* 

LOUBCUNI'.BUN* 


< Table A-7 > 


( Table A-8 ) 


Fig. A. 5: 


"Bakery Problem" Terminology Phase. 
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)t M NOTE ; Lines stBrtins with are 'Cement' lines. 

3(( *1' S& & X* « X*XX»X»X«XXXxXKXXXXXffi;«asss“ -rj-«-tSSXXXSsX = StXX~-~ — — — — — 

* PROBLEM STRUCTURE 

4ia: xxs X s:K*B«sx W'xar.xffi” «xxxxxxaxxxxxxxxxx=xxxxxx=xxx===ssxx- 

» OEJECTIUE 

MAXCBREAB : PROFIT eBREi=iB*BREAD?3 + CEUN: PROFIT ^BUN*BUN?3 

3*. CONSTRAINTS 

* Caracitw Utilization for Bread 

SUHC BREAr»;REQ*BREAruSTAGF3».BREAP?3 AULBREAIu STAGE 
Jic Capacity Utilization for Bur» 

SUHt BUN:Ri:Q.BUN\STAGE3fBUN'5’3 < 5 ^ AVLBUNeSTAGE 
» Cfilifi^ or» Bre-cd Production 

PREAr.* ' ** Uf PQUNTeFFtEAI' 

^ CeilirtSi oti Bun f roductiort 

BUN'^ rx UFBOUNIuBUN 

Minimuni product iori of Bread 
LDUBOUNluBREAn 
Miiiin.un. FToduction of Bun 
BUri^ : ^ tOWBPUNluBUN 


Fig. A. 6* "Bakery Problem" Model Structure 



lamp ’’HELP" pile. 


This dc.cun,ent describes the usese of the Lfthr { Lar.suese 
Aided Hathenistice) f’rosi smmins ) sssteni based ori PASCAL 
lar.sussle end is csfahXe of Ser.eratins Linear PrDaran,n,ir,s 

models • 

The salient features of the ssfsten^ are: 

It is interactive end user friendlst ie. the 
systeni issues niesseses with eroniet for reeuired inf orn.et i on 
or syntaclaccl error arid o;;eculiori coritinues onls* afitM 
acc er table ir»f ot nist lori is supplied bs user in the desis'ned 
forB*at.So in sav that error correction is done then and 
iht‘re*The t eif‘«»i!>c»l messases with r ronipt era apeouate for 
ir»f ut arid e;u 3 aifiat iort required to use the system* 

HN 1 sufitar, of the sssten. isouite sindlai to 

< 3 lsebruic ncftaliuii to ^^el^' thje niodellei . 

3* The three basic phasc-i of the niodel develop nenl are 
1ern,inoU»5iut Iialcbast' and Abstract model* 

A* It aceejts dec 3 c- rat ion ot abstiaci nodsl in £r:Slisr. 
lire lr?i5’.uaci: end devaloes t^J€■ niodcl in alsebraie forni* 

S. Identifiers can be described in abstract form us ins 
molecules < ter ms }*Thc system Generates all possible 
contbi fid i ons ifi the pattern of cartesian product and issues 
pTomrl for each ideritifier dais value entry* 

3 deriiif ier^ I for data values 

identifieriP : fot identifier variable name 

ideriiificr? t for dec cri bins identifier variable 



■6* Nov’ice ufi©r sto for in'Lersdivc* ses,siof> or 

©Tilrw uPto 't€?T*ii;inolo^y dnd dst^sbs&c pJ>ss0 
through fil® and user with some LF' bseksirourid may provide 
ir.formatior, pertaining J;o all the phases through MIC file. 

7* In the abstract model development phase objective 
function and whole bunch of constraints are developed usins 
identifiers and molecules . Identifiers not defined earli^'v 
can also be declared now. 


The various modules of the system perform the 
sublast of niode'l devel of merit as described below I 

1 .liOMDLECULE : 

Eriters terms of Terminolo^v! phase* 
2*CHr:C(>HDLECULE : 

Checi.s the tsTn. for blanl-.s ir. tspins error* 
7.bDATD'" ; ' ' 

EnlCTr list c-f clon.£ in Tern.irio] css phase. 

4. ritUAr; : 

Sets decision variable in atomic form. 

5. AbbATDIi : 

Enters atoms in latter stasc* 

6. REAriircNT : 

V 

Reads 'identifier as typed bs user on 

terii'.i ri£.3 . 

7.Ii0iriENT : 

Checks foT validity of idtritifisi • 

7.S WmXlitKl : 

Set: identifier used ss decision verioWe* 

7. b hataU'Ent : 

Sets identifier dsts values as supplied by 


user 



8.D0CHECK 


. ^ -r identifier components with resr-ect to 

declared ii>olecule^» # 

9.r»0C0NSTFv-AINT J 

Selects 8PF ropriete procedure after checl.ins 
the cofistraint type for addins further constraints as 
described ir« abstract fornu 

10 aiiENT CHECK : 

Checks the corfstraint eoustior. identifier 
match with database phase declared identifiers* 

ll*SF'n»ENT : 

Accepts identifier in special cases as 
suasesied bv uset'^ 
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21*D0FILE : 


leriBinolosa end database f-hase 
sef^arate e.jterrisl file* 


in^ul throuab* 


2X.a DAT Ante : 


Accefts the data values for separate 

e>jterrial file. 

22.compre:ss : 


, , , Con.!^resses the identifier name ren»ovins 

blanks . 

23. £DUATI0Nr0RH : 

Generates e:<Far(ded equation forn< of model 
developed bs‘ LAHP. 

24. GrHrs : 

Oeric rates eiiterrisl file (FI) bavins niodel 
f orufulsi jLori in iridusirs standard HF’S fornist. 


HODa DEUELOF'MFNT Algorithm : 

; Declare holecules. 

Stej ““2 * Declare Atonis uricie-r each molecules 
if ans. 

Sti'j “3 ; Iieclare decision variable if other 
t)i©r( molecule. 

Zii‘i-4 t Dec 3 ar e reeui red idt'ntifie^ and 
e:*ler the vclues. 

Sle'^E : DcClart cbJe-rtive furirtion and 
whole buiich dV coristraintr in 
abstract forn. . 

SYNTAX for objective f urictiori/cofistrsirrls : 

sREt' could be <= or = or >=• 

ol:*uectivfc furictiori 

HAX DT HIN Edvar : identifier t dvar'i^l 

cons traints 


molecule ? <REt':- ideritifier 

SUM t mclecule I molerulc^ ? 1 nREL':- ider>tifier 
SUh C molecule * identifier i mc-lecule ? 1 cREL-' i 
Eriami^lC' session 3 Froduct-Miii problem. 

1. Declare holecule t pRODUCTrCGHPNENT 

2 . Declare Aiorrs for each? if aris : 

PRODUCT =PA f PD r PC f PD t PE 

COhPNENT =R£SI STOP r CAPC 1 T OF: r T F ORhER » £f’£AKEF( 
3.1>e‘c3arc clecisior. variablef if any : 


deritif ier 


.lEISTOR 



declare idanlif ier : 

RTQ.F'ROnUCT ,COMF‘NEN7« 

pRorn,pRoi«ucT« 

INVENTRY^COHF'NENT f 
CEIlIN6,f*RDDUCTf 

5*r»ec23re objective function and constraint : 

H AX t PRODUCT : PROF I T , PRODUCT^PRODUCT? T 

SUMCPRODUCT *REQ ♦PRODUCT •COMPNE.NT)IF'RODUCT'?3<~ I REENTRY « COMPRENT 
PRODUCT'? CEILING, PRODUCT 


! INPUT PILE CPP2 CONTENTS ARE GIUEN ♦,,,,, 

PRODUCT^ PA f F'P » PC » PD f PE 

COHFNE:NT=^RESlSTORrCAPCnOR,TFORMER,SPEAKER.TSISTOR 
5^ identifiers 

RE D ♦ PRODUC: T . COHPNENI i 
E'ROFIT ♦F-R-ODUCT* 

INVENTRY,CObFN£NTI 
CEILING, F'f<DMICI« 

obuortivE fur>ction and constraints 
HAXC PRODUCT J f lCOr 1 1 , PRODUCT 5f;pRDDUCT73 

SUHCPRODUCl :RFa.r*K'nDUC’l ♦CnflPNENTXF’RCDUCTTI :>INUENTRY.C0KPNENT 
F-RODUCIT CL I L INC , PRODUCT 

5F idiJ'tif iOT' data values 4,,,, 

3^0 2^0 1,0 1,0 2.0 

4*0 3.0 3.0 3.0 3.0 

0.0 2.0 3 .0 0.0 2.0 

3 . 0 2 .0 3 . 0 0 . 0 4 ♦ <t 

0*0 6.0 2.0 2.0 8.0 

2.0 4.C' 8>.0 6.0 2.0 

2000.0 3G0C.0 7b0.0 GOO.O 22b0.0 

200. C< 3bC *C CC.O 40: .0 .0 


* ACTlIAl TlRhlNAl. SISeiDN NDu FOLlDUS. ... 


♦EX SRI R. PAS 
LI nr; Load! ns 

LLNf.XCT SKIP ejiecutior.I 


PLEASE TYPE IN ONE OP THE POLLOUING: 

S :T0 GIUE THE DATA E-'Y YOURSELF IN THE INTERACTIUE MODE 
F ;T0 tare THE INPUT DATA PROP. A FILE 

;■ I r 

PLEASE TYF*E IN THE NAPE OF THE FILE <onls 10 chr width is pern-itted) 
.:-'.€PF2 

RILE NAME ;CF*r2 


YOU UANT TO ENTER BASIC HODULES :(Y/N) :Y 
PLEASE TYPE IN ANY ONL OF THE FOLLOWING FOR 
1 FOR 

2 FOR, 'ADDING SOME MORE TERMS' 

3 FOFv* 'ATOMS' 

4 FOR 'ADDING SOME MORE ATOMS' 

5 FOR* 'IDENTIFIERS' 


6 


S 


FOP 'CONSTRAINTS' 
FOF-: 'ODJECTIUE F 
FOR 'GENEF^AL TYPE 


UNCTION' 
CONST RA INIS' 


WHICH YOU WANT TO DECLARE 





THE BECLARATION IS I«ONE FOR' tt IDENTIFIER'S *» 

THE INFin IS BEING READ FROH THE INPUT FILE :CPP'^ 

PRODUCT ' ‘ 

PA 

PB 

Ft, 

PU 

PE 

cohpne:nt 

RESISTOR 

CAPCITOR 

TTORHER 

SPEAKER 

TSISTDR 

YOU WANT TO GOTO OTHER hODULE’ OF HODEL (Y/N) : Y 
F'LEASE TYF'E IN ANY ONE OF THE FOLLOWING FOR WHICH YOU WANT TO DECLARE: 
1 FOR 'TERHS' 

t FOR ^ADDING SOME MORE TERMS^ 

3 FOR 'ATOMS' 

FOR 'ADDING SOME MORE ATOMS' 

G FOR 'IDENTIFIERS' 

6 FDR 'CONSTRAINTS' 

7 FOR 'ODJECTIUE FUNCTION' 

8 FOR 'GENERAL TYPE CONSTRAINTS ' 

" 7 

THE riCCALRfilJON IS BflNG BONE FOR THE OBJECTIVE FUNCTION 
YOU WANT TO HECLftRE SPECIAL CONSTRA3 NT ( Y/N) :N 
PLEASt TYPE IN THE OBJECTIVE FUNCTION IN THE FOLLOWING WAY 
MAX 'HINnEPM;’: iriENTIFlEP*TERhe2?3 

HAXCl'NOnun IF'KOFIT .PPOIIUCT*PROIIUCT?.T 


YOU WANT TD GOTO OIHL'FC MOHULE OF KDIiEL (Y-'N) : Y 
PLEASE TYPE IN ANY ONE OF THE FOLLOWING FOR WHICH YOU WANT TO DECLARE: 
1 FOR ■ TERNS' 

:■ FOR 'ADDING SOME MORE TERMS' 

3 rOR 'ATOMS' 

A FDR ADDING SOME MORE ATOMS 
0 FOR 'IDENTIFIERS' 

« FLU; 'CCINSTRAINTE' 

7 FOR 'OBJECTIVE FUNCTION' 

£! FOR 'GENERAL TYPE CONSTRAINTS' 

6 ) 

THE DECLARATION IS DONE FOR THE CONSTRAINTS 
YOU WANT TO DECLARE SPECIAL CONSTRAINT < Y/N ) 5 N 
PLEASE TYPE IN THE CONSTRAINT IN THE FOLLOWING FORMAT 
SUMCTERM0:iD£NTIFIER)»?TERM02?3 (<=) OR ( = ) OR (>= ) TERMIlHS vn 
PUT ?? FOR NON-LINEAR TYPE CONSTRAINTS 
PUT > INF'LACE OF 3 FOR RHS AS VARIABLE 


SUMCF'RODUCT : Fv'EO - PRODUCT ^COHPNENTJ^F'RODUCT^ 3 <=3 NVENTRY^CDMPNENT 
YOU WANT TO DECLARE MORE CONSTRAINTS (Y/N) ;Y 
PLEASE TYPE IN THE CONSTRAINT IN THE FOLLOWING '^ORMAT 
SUMLTERMO:iDENTIFIERTTERM02'?I <<=) OR < = ) OR <■>=) TERMFJ.S 
PUT ?? POfs NON-LINEAR TYPE CONSTRAINTS 
PUT > INPLACE OF 3 FOR RHS AS VARIABLE 


PRODUCTT- - CE I L 3 NG * PRODUCT 

YOU WANT TO DECLARE MORE CONSTRAINTS <Y/N) IN 
YOU WANT TO GOTO OTHER MODULE OF HODEL <Y/N) I 
YOU WANT TO ADD MOF<E CONSTRAINT DIRECTIY cY/N) 


N 

:n 


EXIT 
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PRODUCT-MIX (INVENTORY) PROBLEM [l3l]s 

A manufacture of electronic equipment (equipment items 
A, B, C, D, and E) finds out that there are certain components 
in inventory that will not be used in the recently redesigned 
products to be produced next year. Thus the management 
desires these components to be used before the end of the 
year, in the current products, to the best profit advantage. 
Otherwise they must be shipped to subsidiary plant. The 
quantities of the components available in the inventory are 
shown in Table B-l. 


Table B-l! Available Components in Inventory 
Resistors Capacitors Transformers .Speakers Transistors 
2000 1800 750 500 2250 



in the inventory as shown 

Table B-2 « 
Prodjuct ^ _ 
Resistors 
Capacitors 
Transformers 1 

Speakers 1 

Transistors 2 


Utilization for Products. 

. . . _ - ' "i5 ' ‘ ' "e 

4-35 
3 2 2 6 

1 1 1 2 

1 - - 2 

3 2 4 8 


Each product uses certain quantities of components left 

in Table B-2 . 

Components 

A 

3 
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A consultation with sales department has indicated 
that atmost 200, 15O, 50, 400 and 5OO units of products 
A, B, C, D and E respectively can be sold within the remain- 
ing months of the year. The maximum expected sales and unit 
profits for products are summarized in Table B-3 . 

Table B-5 ' Majeimum. Expected Sales and Unit Profits. 

Product ABODE 

Maximum Sales 200 150 50 400 500 

Unit Profit 248 62 

In order to maximize the profit, how many of each of 
the five products should be produced so that as many electronic 
components as possible can be used from the inventory for 
production. 



APPENDIX C 


LAMP SYSTEM DOCUMENTATION 


The modelling language system LAMP (Language Aided 
Mathematical Programming) is based on PASCAL and is designed 
primarily for linear programming modelling situations. LAMP 
uses "molecule' and "ATOM" in place of set and set element 
used in the existing modelling languages. In LAMP, variable 
may be a ’MOLECULE" or an "IDENTIFIER" which may be scaler 
or arrays indexed over the molecules e.g. , "¥ATER» CROP, MONTH " 
to represent water required for a crop during a month. 

The modelling system LAMP has been built up using 
modular approach. In order to construct the complete formu- 
lation of a linear program, various modules of the LAMP system 
has been designed with subtask mentioned against them. The 
complete formulation is done in two phases viz, terminology 
phase and abstract model phase. In the terminology phase, 
molecules, atoms, concatenated identifiers and decision 
variables are defined which are used in the next abstract 
model development phase where objective and set of constraints 
are constructed for a particular linear program. 
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'I'he various modules of LAMP ares 

(a) DOMOLECULEs This module defines the molecules of ter- 
minology phase and lists all of them after some preliminary 
checks s using "CHECK MODULEl' 

(b) CHECK MOLECULES This module checks the molecule name 
for any errors due to the typing and assists the "DOMOLECULE" 
module in having such validity checks. 

(c) DOATOM!; This module defines the list of atoms or 
elements corresponding to each of the molecules defined ear- 
lier by "DOMOLECULE" module and finally lists all the atoms 
for user verification. 

(d) PSETVARs This module defines the identifier type decision 
variable in atomic form using previously defined molecule 

and atom names. 

(g) ADDATOMs This module 'adds more atoms in specific situa- 
tions, if required i.e., in the case of special periodic type 
of constraint of abstract model. 


(f) READIDENTs This module reads identifier as typed by 
user in some si^nation, if not defined or declarea earlier 


during the terminology phase. 


(g) DOIDENTS This module has tw sub-modules viz. , "DVARIDENT 


and "DATAIDENT". Depending upon the declaration i.e. 
f ier name ending with " @ "for ' DVARIDENT and "$ " for 


5 identi- 

"dataident ", 
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mad© by user the particular sub“*niodule is activated to fulfil 
the desired task after checking the validity of the identifier 
name with respect to declared molecule and atom names, using 
the modude "DOCHECK". 

# 

(i) DVARIDENTi This sub-module defines the particular 
identifier name as decision variable "DVAR" and sets them in 
compressed atomic form using module "PSETVAR". 

(ii) DATAIDENTt This sub-module defines and sets the identi- 
fier data values as supplied by the user, during interactive 
session of modelling or thro\agh external file in batch 
operation. 

(h) DOCHECK* This module checks the validity of identifier 
components with respect to earlier declared molecule names. 

With above mentioned modules the ^terminology phase of 
model building is accomplished. Following are the modules 
that assist the user in construction of the abstract model 
phase of model building.. Hereinafter "TERM" and "MOLECULE" 
are used interchangeably. 

(i) SPLCONSTJ This module deals with special type of cons- 
traint situation where objective function or constraint is 
having two terms in its abstract form e.g., expression or 
inequality in' one of the following types accordingly. 
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MAX/MIN LTEM0iIDENTIFIER*TERM02?3 

[ TEMO S S IDENTIFIERS ^ERM02S ?'i 
SIM[ TERMO S IDENTIFIER*TERM02 ?] + 

[ TERIVIOSS IDENTIFIERS*TERM02S ?] 

<=/=/>= TERMRHS 

MAX/MIN [ TERMO IIDENTIFIER*TERM02?] + 

ALPi-IA [TERM0SaDENTIFIERS*TERM02S?] 

SUM[ TERMO i IDENTIFIER*TERI^02 ?] + 

ALP,HA[ TERMOS^ IDENTIFIERS*TERI'402S ?] 

<=/=/>= TERMRHS 

The module "SPLCONST" utilizes its sub-module "DOSPRIOR" 
for some prior analysis and structure (format) verification 
of the given special constraint and then develops associated 
ob^jective or constraint (s) using modules "CONSSET” and 
"GENCONS ", For the objective or constraint structure having 
"ALPHA" in the abstract model form the user is required to 
provide the value for "ALPHA" at the time of execution. 

(j) DOCONSTRAINTi This module first checks for various 
structure of constraint type in abstract form i.e., whether 
it is special, having two terms as described earlier in 
module "SPLCONST" or having single term. Then using "DOPRIOR", 
this module docs the prior analysis for determining exact 


pattern of constraint type such as bound type, s im ple summa- 
tion type or general type, matching with only one term of 
pattern shovm in module "SPLCONST". Based on the result of 
prior analysis, it invokes either the module "DOBOUIMD'' or 
"CONSSET" and "GENCONS". 

The various structures of possible constraint types 
should be as 

TERMO ?>=/=/>= TERMRHS for bound type 
SUM[TERM0!TERM0?] <=/=/>= TERMRHS 

for simple summation typ 

SUM[ TERMO aDENTIFIER*TERM02?] <=/=/>= TERMRHS 

for general constraint type with 
single term only. 

(k) IDElMTCHECK'i This module takes the abstract form identifier 
and checks for its match with earlier declared identifiers 

and sets some indicator (signal) accordingly for specific use 
later. 

(l) SPIDENTS This module accepts or defines a new identifier 
in special cases. Whenever an abstract form identifier is 
not found to match with already declared identifiers the 
system asks the user for its validity as new identifier. This 
also uses the module “IDENTCHECK" for verifying identifier 
components. 
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(m) DOPRIORs This niod.ul6 makes prior check of syntax for 
abstract constraint in row-wise organization and after elimi- 
nating blanks, checks for all special characters which are 
used as indicators for different constraint type determination. 

If required in some cases, it can provide nonlinear type cons- 
traint euialysis and parameter value fixation by user. 

(n) REiUDRHSi This module reads right hand side (RHS) identifier 
of abstract form constraint viz. "TERMRHS" and displays the 

same on terminal for user verification. 

(o) COMSSETj This module makes identifier component (part) 
match check with the decision variable of the given abstract 
form constraint and uses module "IDENTCHECK" for identifier 
match with already declared identifier list and then depending 
upon the requirement^ invokes modules "READIDENT" or "SPIDENT 
and "READRHS” based on specific response from the user. HenCe 
this module sets the various components of abstract form 
constraint after the validity checks for associated variable, 
coefficient identifier, right hand side identifier (TEKT'IRHS) 
and summation index (TERMO) are made. 

(p) DOBOUNDs This module generates simple bound type cons- 
traints from the given abstract form 


and finall^^ writes the corresponding inequalities in e 3 <panded 
form. 

(q) SUMiYPECONS* This module generates a constraint similar 
to generalized bound (upper or lower) type from the given 
abstract form constraint as 

SIJM[ TEFMO S TERMO ?] <=/,&/>= TERI'IRHS 

(r) GENCONSs This module uses the sub-module "GENIi/lT " which 
sets the constraints in general expanded form. Using the 
results of module "CONSSET" which checks the part (component) 
successively, it further checks whether the abstract form 
constraint identifier matches with the earlier declared 
identifiers having data values stored in the system. Later, 
using an index function the proper coefficient values are 
retrieved from the array containing the data values for 
particular identifier. Finally, based on "TERjyiRHS” identifier 
name the constraint name(s) is also set and stored in the 
system. This module uses "DOMATGEN" to write the matrix 
co-efficients. 

(s) DOI4ATX5ENS This module writes the generated matrix 
coefficients for visual aid to user on terminal. 

(t) GCONSTNAMES; This module sets the name of the constraint 
as provided by user for the modelling situation using module 

"GENTYPECONS" dealing with periodic type constraint. 
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(u) GENTYPECONSs This module generates periodic constraints 
having one period lag component. This invokes module 

"GCONSTNAME" for labelling various constraints, 

(v) DOFILEs This module provides the facility of generating 
the linear program model in batch mode for a professional 
user, if he opts for the same instead of interactive session. 
In the batch mode modelling he should provide all the relevant 
information needed for model building in certain order through 
a separate external file having entries as below. 

X' M0LECULE1=AT0M1 , AT0M2 , , , . 

CR0P=C0TT0N , ONION , APPLE , ORANGE 

*IDENTIFIER(S) 

V/ATER. CROP. MONTH I 


* ABSTRACT MODEL OBJECTIVE/CONSTRAINTS 
MAX[ CROP S PROFIT . CROP^ CROP ?] 

SUM[ CROP i WATER. CROP.. M0NTH*CR0P ?] < = WATERAVL . MONTH 


* IDENTFIER DATA VALUES IN SAtVE ORDER OF IDENTIFIER 


95.0 
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Thus using sub-module ’’DATAFILE' this module accepts 
input through an external file for molecules, atoms and 
identifisrs, Furthsr this module alongwith command file 
and the same external file having information for objective 
and constraints in abstract fonn completes the modelling of 
linear program based on information constrained in the above 
mentioned files. 

(w) EQUATIONFORMl This module generates the entire model 
formulation as linear program in expanded form. The whole 
bunch of constraints alongwith objective fimction at the top 
of it is written on a separate file named "F2 " which can be 
utilized further by any problem processor for obtaining 
solutions to linear program. The problem processor used in 
our cast' is LINDO [1^5], Further as LINDO does not accept 
more than 132 characters for input in a line in the form of 
objective function as well as constraints, the same has been 
implemented as a specific requirement, which need not be so 
in general. 

(x) GFMPSS This module generates the model formulation in 
industry standard MPS format [92 ] acceptable to most of the 
existing problem processors e.g., LINDO and others. By 
invoking this module, the model formulation of linear program 
is written in MPS format on a separate file named "El" which 
can be utilized further by any problem processor for obtaining 

solutions of the modelled linear program. 
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Thus the major task of model formulation is achieved 
by the above mentioned modules. However, some small modules 
also assist in accomplishing the above task viz., 


PREAD 

PmiTE 

PLNREAD 

COiyiPKESS 


It reads a character from the terminal. 

It displays a character on the teminal. 

It reads a character from a nev/ line. 

It compresses the identifier name after removing 
the blanks . 


Apart from the above, LAI'IP can also generate model 
formulation for transportation and assignment problem by 
invoking modules "TRAI'ISPORT" and "ASSIGNMENT" respectively 
in standard formulation pattern. 
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LINTEAR INTERACTIVE AI'JD DISCRETE OPTIMIZER LINDO 

LINDO (Linear Interactive and Discrete Optimizer) is 
an interactive linear, quadratic aiid integer programming . 
modelling language system developed by Linus Schrage at 
Graduate School of Business, University of Chicago, USA. It 
is a small scale system designed to be useful to a variety 
of users. The major design consideration has been that if a 
(potential) user wants to do something simple, then there 
should not be a large set-up cost to learn the necessary 
features of modelling language system LINDO. LDIDO has been 
in use since 1931 for solving real industrial linear, quadratic 
and integer programs of respectable size. Several versions 
of LINDO have been implemented on main frame, mini and micro 
computers of different computer manufactures viz. DEC, IBM, 

Data General, Honeywell, Burroughs, CDC, HP, Uni vac, etc. 
on DEC-20 computers it is typically configured to solve 
problems with upto 800 rows and 4500 variables. This capability 
is generally increasing with each new version of LINDO. It is 
biased towards the user who is interested in developing and 
solving formulation of real life problems from diverse fields 
of military, industries, agriculture, transportation and 
service sectors. 
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LINDO is designed for interactive computing. However, 
it can be run in batch mode with no modification through 
external file on a batch system. LINDO is command oriented 
rather than menu oriented. Thus it does not restrict any 
user to go through fixed sequence of steps allowing only 
small options along the way. User can select from wide range 
of commands in, any order as per his specific modelling 
requirement. It can be run in a conversational style. 
Introductory help about the system features are provided by 
'HELP", "CATAGORIES" and "COMMANDS" commands. Using them 
user can get the list of all commands available, which are 
grouped into categories according to use e.g,, input, output, 
etc. Then using '’HELP " followed by any command name he can ge' 
the detailed information of specified command. 

LINDO user can divert the solution and model formula- 
tion of real life problem to a designated external file. 

LII'IDO has file output commands for two purposes* 

. Store a problem foraiulation", 

. Store the results of computation. 

User can provide model input to LINDO through external 
files which may have input information either in industry 
standard MPS format or in expanded inequality form. LINDO 
has specific commands for taking input from files. The MPS 
format for describing an LP is widely accepted industry format 


The MPS format has from three to five sections ^ "ROWS" 
"COLUMI'IS", "RHS", "BOUiJDS", "RANGES". 'BOUNDS" and "RAl^GES" 
are optional . 

The "ROWS" section lists the row names, one per line, 
with the name preceded by its type. An "L" means (< =), 
an "E" means (=) , a "G" means (>=) and an "N" means not 
constrained (e.g., the objective fimction row). 

The "COLUMNS" section lists each non-zero element of 
the matrix preceded by the column name and row name in which 
it appears. 

The "RHS" section lists each non-zero right-hand- side 
element preceded by the name of the row in which it appears. 
One must also give a name to the right-hand- side i.e., "RHS". 

In MPS file form of input it is allowed to have several 
non-constrained rows i.e., multiple objectives can be listed 
by assigning "N" alongwith particular row name having objecti'v 
function. The system asks user to indicate the particular 
objective function to solve the model formulation through 
fiven MPS file alongwith the information regarding maximiza- 
tion or minimization. 

LINDO provides an elegant problem summary (e.g., number 
of rows, number of variables, number of integer vari^les, 
number of non-zero elements, number of non-zero constraints. 



matrix density, sm^lest and largest element in absolute 
value., number of less than equal to constraints, number of 
equal to constraints, number of greater than equal to cons- 
traints, objective function, number of generalized upper 
bounds, etc.). This summary is quite useful for model 
analysis of large problems. Model validation before solution 
is an essential task for a large size linear program. In 
the case of large linear program model the variables may 
be misspelt, the sign of coefficient may be wrong, the 
coefficient may be in wrong constraint, the coefficient may 
be associated with wrong variable, the decimal point may be 
misplaced. Such errors may lead to absolutely erroneous 
solution which necessarily have to be eliminated before 
model being run for solution. In this context model analysis 
capability of LIIIDO in the form of problem summary is commend- 
able. 

LINDO is quite useful for mathematicians as it is 
capable of providing several analysis of working of Simplex 
method. LINDO uses Revised Sinplex Method. Various commands 
allow user/analyst to study the mechanics of the Simplex 
method for solving linear programs. One may optionally 
include a variable name after the word pivot, e.g., "PIVOT 
COTTON" , in which case the named variable (e.g, , ’’COTTON" in 
this case) is made to enter the solution. One may optionally 



include a row number after the variable, in which case the 
pivot will be made in the specified row. LIHDO has the 
features for the mathematician who may be interested in 
displays of the tableau and some other steps of Simplex 
method. Specific commands in LINDO provide insight into 
the workings of the revised Simplex method, "IInP/ERT " command 
reinverts the cixrrent basis i.e., it re-solves the set of 
simultaneous linear equations implied by current basis. The 
inverse is represented by product of elementary matrices 
(i.e., identity matrix except for one column). Inversion 
tries to permute the rows and columns of the basis so that 
the matrix is as close to the triangular as possible because 
a triangular system of equations is easily solved by back 
substitution. 

In order to study the effect of various parameters on 
the optimal solution, LIMDO provides specific commands. The 
"RANGE" command causes a standard range report to be printed. 
This report specifies the allowable changes for objective 
function and right-hand- side coefficients which will not 
cause a change in basis. LINDO allows for sensitivity 
analysis also. 

LINDO has a quadratic programming capability which 
allows the user to consider problems with a quadratic 
objective function i.e., objectives which contain the 
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product of few variables. Users in general be interested 
in whether the optimum found by the quadratic program (QCP) 
algorithm is global optimum or simply a local optimum. If 
the submatrix corresponding to the quadratic part satisfies 
certain conditions then the solution found will be global- 
optimum. One condition sufficient to guarantee global 
optimality is positive definiteness. 

LINDO allows variables to be integer. It can be 
general integer variable or zero/one variables. General 
integer variables are identified by specific co m mand. LINDO 
uses branch-and-bound method for solution of integer programs. 

LINDO contains a dummy subroutine called "USER". This 
allows a user to do a variety of things, such as write a 
special purpose input/output procedure or incorporate LINDO 
into larger systems. 
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UNTFY RELATIONAL DBMS SOFTWARE 


"UNIFY" is a relational database management system 
software developed and supplied for commercial use by UNIFY 
Corporation, Portland, Oregon, USA. "UNIFY" is based on 
"UNIX" operating system, Ul'IIFY is a collection of over twenty 
different programs, all integrated together to let user create 
and modify application systems that store and retrieve data. 
The UNIFY System is menu driven. The primary user interface 
to UNIFY system is the menu handler (MENUH) . The menu 
handler provides the means to let user select any UNIFY 
program he wants, as well as controlling security, so that 
he can deny access to certain programs. This menu handler 
is linked directly with set of utilities viz. , "SQL", "Query 
By Forms", "Enter ", "Database Utilities", "Host Language 
Interface" . All these utilities are directly linked with 
"Unitrieve Data Base Kernel" which is linked with "Data 
Dictionary" and "Data Base Volumes". Report writer is 
linked to "SQL" and "Query By Forms". UNIFY is provided with 
a set of built-in menus ready for user to use in developing 
his application. However, he can also create his own menus. 



In order to exploit the DBMS capabilities fully the system 
menu provides following options* schema maintenance, schema 
listing, create data base, " SFORM" menu, "ENTER" screen 
registration, "SQL”- Query/DML language, "SQL" screen regis- 
tration, listing processor, data 'base test driver, "MENUH" 
screen menu, "I^IENUH" repori; menu, reconfigure database, 
write data base backup, read data base back-up, data base 
maintenance menu. 

The UN'IFY non procedural query and update language 
is an implementation of the IBM-standard structured Query 
Language (SQL). Using SQL, user can interactively add, modify 
delete and query information in his data-base. Moreover the 
user can connect a screen form to an SQL query script and 
then format the results of the query with the primary UNIFY 
report writer, "RPT ". This interface is usually called SG^^ 
By^Fprms, For performing the simpler queries that are often 
more than half of the queries performed, UNIFY offers %iery^^ 

By Forms (QBF) . QBF lets user fill in search va.lues on a 
screen form, which is used to find the records that match. 

User can look at them one at a time on the screen fom or 
he can send the results to one of the UI^IIFY report writers^ 
'RPT " which is powerful, listing processor "LST" -tdiich is easy 
to use. 

Full screen data entry is handled by the utility 
"ENTER". ENTER performs many kinds of edit checks including 



type, length, date and time formats, amount formats, and 
table look-up. In addition, user can add his own functions 
to customize it further. ENTER uses the screen forms 
that can be created and modified using the SFORIi utilities. 

The utilities necessary to create and maintain a 
database includes programs to enter and modify the database 
design (i.e., schema design); create and reconfigure the 
database, maintain field level securily; print statistics, 
read and write back-up- tapes (or floppies); repair corrupted 
data bases; and load in data from ASCII files. The remaining 
part of the structiore- are internal to the system. Although 
operations of UNIFY requires little or no knowledge of UNIX 
or programming, having some background of above is quite 
useful. 

The transaction logging and console monitor utilities 
make the operation of application system easier and more 
reliable by recording all database updates and displaying 
menus for user guidance respectively. 

In order to use UNIFY DBMS Software for the applica- 
tion, user first creates and maintains the schema and the 
database itself using data base maintenance utilities. Then 
using the screen foniu.. tool SFORM data could be entered in 
the database. . The general purpose data entry program "ENTER" 
can be used to drive SFORM Screens. 
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Once the data has been entered in the data base, 
the UNIFY SQL and RPT processors can be used to retrieve 
data or present it in a meaningful format. The UNIFY query- 
language, SQL, is a po-werful subset of the IBM standard 
relational query and data manip illation language, SEQUEL 2. 
Besides SQL, UNIFY also has a simpler, less powerful query 
interface designed to do file listings with totals and 
subtotals. This program is called listing processor (LST). 

UNIFY can be used as the SHELL. The main shell 
commands ares 

DBLOAD £ This permits loading of data into database from 
an ASCII file. 

LST : This allows producing simple sorted file listings 
with totals and subtotals. 

RPT s This allows producing sophisticated reports using 
a powerful, non-procedural language. 

SQL ; This allows, query and update of a database file 
using powerful, non-procedural language. 

The UNIFY’ s specific features of schema design is 
described below. 

The " UNITRIEVE " data base is set-up and maintained by 
designing interactive schema for appropriate records and 
, their fields using the relational approach. The schema entry 
program uses two screen forms, first for general record 



information (e,g.. Line Number - LI'I, Command tCMD, Record 
name - RECORD, Expected numbers, Long name - LONG NAME and 
Description) and the second for detailed field information 
for the record created . earlier. 

The various user assistance prompts of paging area 

are* 

n - displays next page of data base record type. 

p - displays previous page of data base record t3?pe. 

a - permits adding of new data base record t 3 /pe. 

The various command area options areJ 

f - modify the fields for current record type. 

m - modify, expected, long name and description for 

the current record. 

d - delete current information (record). 

q - redisplay the paging prompt at the bottom of 
the screen. 

Some of the restrictiorP on the record and field details 
are as follows^ 

A record can be given a name of maximum eight charac- 
ters having upper and lower case letters, numbers and under 
score character (_) beginning with letter only. Long name upto 
sixteen character length with other features similar as record 
name can be given which is used by "ENTER", "SQL" utilities. 
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Description can be used as "Comment" field for description 
of record. 

The field inf ormation ( e , g . , Line number - LN, 

Comm.and -CMD, field name - FIELD, Key - KEY, Reference - .REF, 
Type - TYPE, Length - LEN, Long name - LONG NAME and Combi- 
nation B'ield “ COMB) can be set for any record using prompt 
"f'' in the command area of record schema maintenance. "Field 
name'' has the same feature as that of record name. Asterisk 
(*) is the entiy to be made in the ’'KEY" column to indicate a 
particular field to be treated as key field. 

"REF" column is used to establish an explicit relation- 
ship with another record t3^e (i.e., linking with some base 
field.) The "TYPE" column is used to indicate the different 
data types associated with the field using first character 
as follows 5 "n" for "NLlffiRIC; "f" for "FLOAT ","S " for ■"STRING" 
"d" for "DATE',’ "t" for "TIME',' "a" for "AMOIDJT" and "c" for 
Combination (COMB). 

The "LEN" column represents the entry for the length 
of the various fields for display. If not provided by the 
user at schema design the system assumes some default values. 
"LEN" has the form"nnd" for float field (i.e., 179 represents 
17 display positions having 9 positions for decimal values). 
"COMB" field column is the unique feature of lEIIFY system 
that it allows user to specify multiple fields as key of the 
record type (relation). 



The "LONG NAME" column is used to give long field 
names (upto sixteen characters). The regular field name 
is valid upto eight characters. The long field names do not 
have to be unique for the whole data base, but the regular 
field names must be. Field names must begin, with letter and 
comprise of letters, digits and under- score character (_) 
having no blanks in between. In case of same long field 
name in different record t3?pe s the particular field name is 
referred by prefixing the record type name to the long field 
name (i.e., iconsn.cons_id or imat.cons__id) . 

The "C0D4BINATI0N" column is used to specify multiple 
field key, if any. 

^hese features are used to create and maintain schema 
in a systematic way. The "RETURN" key on terminal is used 
for forward reference and "CTRL" key along with "U" key is 
used for backward reference alongwith specific options 
selected on the display terminal during the UI'flFY system 
operation. 
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STRUCTURED QUERY LANGUACtE 

The Structured Query Language (SQL) was developed at 
the IBM Research Center as a relational inquiry and data 
manipulation language based on English Ke 3 rword Syntax. Its 
structure was refined through extensive testing to produce a 
language easy enough for non specialists to use, yet powerful 
enough for data processing professionals. SQL is fast 
emerging as the standard relational query language on variety 
of computers starting from main frame to micros. The UNIFY 
implementation of SQL; is primarily based on the language 
description [38]. In order to adapt it to super-micros/ 
minis and the UNIX environment some changes have been made 
to the syntax. Most of the query and data manipulation 
features have been implemented without modification and 
UNIFY’ s SQL is claimed to be the most powerful relational 
data manipulation language available on supermicros. 

SQL is a powerful, English keyword based language that 
lets user specify queries of varying degrees of complexity, 

A query consists of phrases (also called clauses), each 
of which is preceeded by a keyword. 
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These keywords ares 


and 

asc 

avg 

between 

by 

count 

delete 

dese 

edit 

end 

fields 

from 

group 

having 

help 

in 

insert 

into 

is 

lines 

max 

min 

not 

or 

order 

records 

restart 

select 

separator 

set 

start 

sum 

unique 

unlock 

update 

v/here 


The required phrases (clauses) ares 

select - Some data (a list of field names) 
from “ Some place (a list of record types) 

The optional phrases ares 

where - a condition (a true/false statement) 
group by - some data (a list of field names), 
having - a group condition (a true/falsa statement) 
order by - some data (a list of field names) 
into a file name. 

The relations (record types) and fields to be used in 
selection and calculation are identified by the relation 
names and lon g field names (maximum of sixteen characters) 
fhom the UNIFY schema design for the database. Schema design 



of UNIFY permits both regular short names (upto eight 
characters) and long names (upto sixteen characters) for 
naming of the fields. Long field names donot have to be 
unique for the whole data base; but the regular field names 
must be. In case of same long field names in different 
relations the specific field name qualification is done by 
prefixing the relation names, Valid field names should begin 
with letter only and comprise of letters, digits and under, 
score character (_) having no blanks in-between. 

SQL allows free form input - line can be spaced across/ 
many statement clauses can be compressed in a line* This 
means that extra spaces and carriage returns may be used 
freely to improve the readability of a query statement, without 
changing its meaning. A query is ended by the slash character 
(/), at v/hich time SQL begins the evaluation of what user has 
typed. If the user entered a valid query, the message in 
response to slash character is "recognised query". If the 
query had some syntax error and SQL was unable to understand 
the user query, an error message is displayed on the termi- 
nal that gives user an idea as to what kind of error was 
made by him in writing the query statement. 

UNIFY* s SQL provides three kinds of help that makes 
learning and using SQL easier. User can get help about 
general syntax, any specific keyword, . keyword clauses or 
the valid field names for the data base. 
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The simplest kind of SQL query includes both a "select” 
clause and a "from" clause. The "select" clause lists the 
fields to he printed, while the "from" clause tells which 
record type (s) or relation (s) the fields are to come from. 

As user rarely wants to list the entire contents of a record 
type (relation), the "v/here" clause is provided to let user 
specify selection criteria. The "where" clause lets user 
compare a field with a constant, an expression, or the resiLLts 
of another "select" clause. The "where" clause can also con- 
tain a complex boolean ejcpression composed of selection 
criteria connected by "and"/ "or" operators. Precedence can 
be established by use of square brackets. 

Arithmetic expressions are provided to let the user 
calculate values using the standard operators +, and 

/. Both constants and fields may be used in arithmetic 
expressions, which are allowed on fields of all types except 
string and combination. Arithmetic may be used wherever a 
simple field is allowed in "select" , "where" and "having" 
clauses. 

SQL provides five different built-in aggregate functions 
to allow calculation of aggregate items in a query resifLt. 

The functions are "count («■)", "min", "max", "sum" and ’b.vg". 


Aggregate functions are only valid when used in "select" or 
"having" clauses. User may not use an aggregate function 



directly in a "where" clause, although using nested query 
he can usually achieve the same effect. As natural, an 
aggregate function only applies to a group of records with 
a common characteristic. The "group by" clause is provided 
to allow computation of aggregate function on group of 
records that have common characteristics. Thus using a 
"group by" clause without an aggregate function has no 
meaning. The effect of a "group by" clause is to sort the 
selected rows by the indicated fields, and then perform 
the aggregate functions at each level break. The output 
results are sorted also. 

Nested queries allow user to get answer for a whole 
new set of questions that cannot be answered using the 
capabilities of SQL presented so far. Nesting allows user 
to' use the results of one query as input to another. Thus 
he can use the results of one question in answering another 
one, for example, checking simple upper bound situation in 
our relational database for linear programming model as belows 

Select iconsn. cons_id, consjiame 
from iconsn, imat 

v/here imat.cbhs id = iconsn, cons id and iconsn. cons__id^ 

Select imat.cons__id 
from imat 

where imat.mat__element''''^ =1*, 
group by iconsn. cons_id 
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Qu6ri6s can be nesbed to any iGvel and svaluation 
t&kiss placa from innsninost to outsi'inost block in ordan. 

Nsstsd. Q_u.6Z'i©s can bG usGd in both ''whara" and "having'* 
clauses at the same time. 

The having" clause lets the user select some of the 
groups formed by a previous "group by" clause and reject others 
based on the results of another selection using one or more 
of the aggregate function. This gives user a capability 
equivalent to using an aggregate function in a "where" clause, 
which is not allowed otherwise. 

Thu "order by" clause lets the user sort the output 
of a query. He can specify ascending or descending sorts on 
each field, or can omit the specification entirely. In such 
situations, the default sort order is ascending, with ''STRING" 
fields sorted in alphabetic order from A to Z. 

SQL may list fields from any number of record types 
(relations) in a single query. Queries that list fields from 
several record types are called join queries, because they 
join the different record types together. The different record 
types (relations) to be involved in the query are listed in 
the "from" clause, in any convenient order. SQL then determines 
what is the most efficient method of performing the selection 
and qualification. The fundamental concept underlying join 
queries is that of Cartesian product. Conceptually, a 
join query first forms the Cartesian product of the 
record types (relations) and then filters the result 
by the conditions in the "where" clause. 
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Queries Cdii be nested, to any level and evaluation 
takes place from innermost to outermost block in order. 

Nested Queries can be used in both ** where** and **having** 
clauses at the same time. 

The "having" clause lets, the user select some of the 
groups formed by a previous "group by" clause and reject others 
based on the results of another selection using one or more 
of the aggregate function. This gives user a capability 
equivalent to using an aggregate function in a "where** clause, 
which is not allowed otherwise. 

The "order by*' clause lets the user sort the output 
of a query. He can specify ascending or descending sorts on 
each field, or can omit the specification entirely. In such 
situations, the default sort order is ascending, with ** STRING" 
fields sorted in alphabetic order from A to Z. 

SQL may list fields from any number of record tj^pes 
(relations) in a single query. Queries that list fields from 
several record types are called join queries, because they 
join the different record types together. The different record 
types (relations) to be involved in the query are listed in 
the *'Jrom" clause, in any convenient order. SQL then determines 
what is the most efficient method of performing the selection 
and qua.lificntion. The fundamental concept underlying join 
queries is that of Cartesian product. Conceptually, a 
join query first forms the Cartesian product of the: 
record types (relations) and then "filters" the result 
bv the conditions in the ** where" clause. 
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Thus a join query without a "where" clause does in fact list 
the Cartesian product of the record type. Soinetinies it is 
necessary to .join a record type (relation) with itself. 

Regular nested queries work " from the inside out"^ 
evaluating the innermost query and passing the resulting value 
or values back out to the next outer query. Each query is 
performed only once. Variable queries reverse this proce- 
dure, working "fr om the outside in". This lets the user per- 
form an inner query multiple times using values from the outer 
query. As the inner query varies depending on the record type 
(rolation) in the outer query, this kind of query is called 
variable query , fho inner query to be performed miiLtiple 
times is ended with a semicolon (;) instead of ending the 
query with a slash character (/). 

In addition to above stated query facilities, SQL 
a3.so providers data manipulation capabilities. This means 
user can interactively ins ert , modify and deplete records in 
his database using a high-level, nonprocedural language. 

There is also an interface to the UNIFY database load pro- 
gram "DBLOAD", so user can load a database quickly from 
regular ASCII files. All of the query features of the lan- 
guage are retained H<^rice the user can use regular query 
statements to insert data from existing files containing 
record types into other files, and select records to be 
modified or deleted. Ii/hen a set of records is specified to 
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be modified, that set is locked using the UNIX file locking 
system calls. This prevents several users from simultaneously 
trying to modify (update) the same records. 

The "insert" clause allows the user to add new records 
to the database, using constant value or values returned as 
the result of a query. Only the primary key value must be 
specified. Other field values that are not specified are set 
to thei standard, initial values - zeros for "IWERIC", "FLOAT", 
"AJIOUNT", "TII'E’' and "STRING" fields and null (-32768) for 
"DATE” fields. Besides using literal tuples, an "insert" 
clause c::in use the results of a query statement to obtain its 
values, 

Thu "update" clause lets the user modify fields in 
existing records. Updates can be specified with literal values, 
c-’jqDressions or query statements. A'Vhere" clausa to specify 
which records the update applies to is not required. If it 
is left out, the update is applied to all records of the 
indicated typo. A field can be updated using an expression, 
and more than one field can be changed in a single update 
clause. 

The "delete" clause lets the user delete records from 
an existing file (record type). The records to be deleted 
are identified by a "where" clause or if this is not present, 
all the records for the indicated type are deleted. 



In addition to above mentioned facilities, 
provides several extensions to the basic language 
active query development in the UNIX environment, 


UNIFY’ s SQL 
for inter- 
which makes 


it more powerful. 



